Executive Summary

• SentinelLABS evaluated how frontier models reverse engineer binaries and annotate disassembler databases, finding recurring problems with inaccurate labels and incomplete analysis.
• To improve performance, we developed and tested a standard for LLM-driven reverse engineering that keeps annotations tied to evidence, verifies database changes, preserves project state, and requires review of the model’s work.
• We open-sourced VerifiedIDA, a reference implementation that applies the standard to autonomous reverse engineering in IDA Pro.
• Despite the growing capabilities of new models, our research shows that scaling reverse engineering requires that the analysis they produce remain inspectable, continuable, and reusable by humans, other models, and downstream security workflows.

Overview

The use of large language models (LLMs) for reverse engineering creates the possibility of examining binaries at a scale and speed exceeding that of manual analysis. It also makes reverse engineering accessible to those without specialized expertise in the discipline. The combination of scale, speed, and accessibility introduces a major shift across multiple domains. In cybersecurity, for example, defenders can analyze larger volumes of malware in less time, while attackers can misuse the same capability to considerably accelerate and scale vulnerability research and exploit development, shortening the time to exploitation and increasing the volume of intrusions.

As part of our broader innovation initiative for applying AI to automate and scale up defense workflows to keep up with an increasingly fast and widespread threat landscape, this work contributes to making LLM-driven reverse engineering inspectable, continuable, and reusable. These properties are important when reverse engineering output is used as part of cyber defense operations, such as incident response, detection development, or threat hunting, where analysts act on this output, share it with other stakeholders, and use it as input to other tools and workflows. This requires the ability to inspect the evidence behind an LLM's conclusions to verify them, have another analyst or model continue the work from where the LLM stopped, and reuse results coupled with the code and data they describe.

To this end, we focus on LLM-driven reverse engineering whose output is an annotated disassembler database, such as an IDA Pro, Ghidra, or Binary Ninja database. In contrast to a textual report, which reduces the analysis to a prose snapshot of the model's conclusions, detached from the code that supports them, an annotated database records findings directly on the disassembled code and data, as labels, types, data structures, and comments. 

As a result, an analyst can verify each conclusion against the code and data it describes. When the database is shared with other stakeholders, recipients get every annotation, not only the findings a report would contain, and can verify and use the parts they need. In addition, another analyst or LLM can continue the analysis from the existing annotations in the database or correct them if necessary, rather than interpreting a prose report and locating the code and data each conclusion refers to. Other tools and workflows can also work directly with the findings and the code they apply to, for example, to generate YARA rules that target functions identified as implementing specific capabilities, or to parse configuration data using recovered data structures. 

However, an annotated database provides these benefits only if its annotations are accurate and complete, which LLMs do not guarantee. To understand these limitations in practice, we conducted evaluation studies in which LLMs analyzed binaries and annotated IDA databases without safeguards for the accuracy or completeness of their work.

We first present the results of these studies, which show that models produced inaccurate labels, left some findings unrecorded, lost track of unfinished work, and stopped the analysis early. Full model specifics are provided in the section below.

Based on these findings, we propose a standard for LLM-driven reverse engineering that annotates disassembler databases. Under the standard, each annotation must be confirmed as recorded in the database and traceable to documented evidence against which its accuracy can be verified, outstanding work stays tracked until it is resolved, and an independent review assesses the accuracy of the annotations and identifies work left undone, returning its findings to the LLM that reverse engineers the binary for correction.

Finally, we present VerifiedIDA, a harness that serves as a preliminary implementation of the standard by mediating the LLM's access to an IDA database. VerifiedIDA is released as an open-source project, together with the specification of the standard and a user guide.

Evaluation Studies | LLM-Driven Reverse Engineering Without Safeguards 

The goal of our evaluation studies was to identify common challenges with model-led reverse engineering where the model had to annotate a disassembler database using basic tooling. A detailed comparison of how models perform, individually or by vendor or tier, was not our focus.

We used proprietary models from Anthropic and OpenAI in addition to open-source models to reverse engineer binaries of varying size, both malicious and legitimate. The majority of our testing presented here used GPT-5.6 Sol. The models worked through a simple harness, in which an LLM analyzes a binary autonomously, without any human or automated feedback and with access only to basic reverse engineering capabilities. The harness provides only general instructions and a fixed set of tools for viewing disassembled and decompiled code, following cross-references, searching the binary, and writing labels, types, and comments, such as free-text descriptions of functions, into an IDA database.

The full reasoning of Anthropic and OpenAI models is not available through their APIs, so we could not directly observe how they make decisions while reverse engineering a binary. Instead, we logged each analysis step by step in what we refer to as an LLM log, recording the tools the model called, the code it retrieved, its intermediate notes and planned next steps, and the edits it made to the database. An LLM log may show, for example, the model retrieving the pseudocode of a function, following its cross-references, and then labeling the function in the database. This allowed us to reconstruct what the model retrieved, what it based each annotation on, and how it acted on that information.

To illustrate some of the observations we discuss next, we present two case studies in the Case Studies section, each examining in detail how GPT-5.6 Sol performed a routine reverse engineering task. In both, the model reverse engineered a sample of ComRAT (SHA-1 hash: 0139818441431c72a1935e7f740a1cc458a63452), a backdoor attributed to the Russian APT group Turla. Case Study #1 covers the recovery of a data structure passed as a parameter to two ComRAT functions, whereas Case Study #2 covers the analysis of a single ComRAT function's behavior.

Structured Work Grounded in Evidence

We observed that the LLMs took a sound, methodical approach to reverse engineering tasks. For example, when labeling a variable or a function, they typically started with a broad analysis of the pseudocode or disassembly and then moved to targeted exploration, analyzing how the variable or function is used across the binary to determine the variable’s role or the function’s primary operation, which is what the label should describe.

The models also largely avoided fabrication. For example, when a model could not establish the role or type of a variable, it typically applied a generic label, such as unknown, or a generic data type, such as void, rather than inventing one the code did not support.

In addition, the LLMs made effective use of authoritative information relevant to the analysis, such as the public documentation of Windows API functions, which is highly likely present in their training data. For example, when a variable was passed to a Windows API function, they typed it based on the function's documented parameter types, and when a function called Windows API functions, they took the documented behavior of these API functions into account when determining the primary operation of the calling function.

Inaccurate and Incomplete Disassembler Databases

Alongside the strengths discussed above, we observed four major, recurring problems. These problems undermine the purpose of an annotated database as the primary output of LLM-driven reverse engineering, which is to serve as an accurate and complete binary-grounded foundation for any downstream use.

Accuracy of labels 

Some labels the LLMs applied to variables and functions did not accurately describe the variables' roles or the functions' primary operations. This matters because analysts often rely on labels to navigate an annotated disassembler database. Inaccurate labels therefore have consequences for anyone who uses an annotated disassembler database, human or model, whether to continue an analysis or to draw conclusions from it. For example, an ambiguous label may lead an analyst to redo work that is already done, while an imprecise one may draw attention away from binary behavior that matters. 

Inaccurate labels also misrepresent the binary under analysis, and any conclusion drawn from the database carries that misrepresentation forward. In addition, the inaccuracy of a label is not apparent from the database itself, since a label says nothing about how well it is supported. An inaccurate label is therefore either taken at face value, with the consequences that may bring, or caught only at the cost of redoing the analysis whose conclusion it was meant to record.

Capture of findings 

The models repeatedly established findings during the analysis without recording them as annotations in the databases, that is, they did not reliably translate reverse engineering findings into database annotations. These findings did not survive the analysis sessions, and the effort behind them was effectively lost, leaving the databases incomplete.

Continuity of work

As the analyses progressed, the models often lost track of unfinished work, which we suspect is primarily due to context compaction, the condensing of the models' earlier output and tool results to fit their context windows. Steps they had planned were dropped, leaving the parts of the binary they targeted unanalyzed and without annotations in the databases.

Completeness of analysis

The LLMs often stopped exploring before examining all the code relevant to what they were analyzing. For example, having settled on a function's primary operation, an LLM labeled the function without exploring all of the function's callees, some of which implement additional capabilities. These capabilities remained unidentified, and the function's label did not express them.

Reverse Engineering Standard

The four problems we observed are not variations of a single failure. Each points to a responsibility that cannot be left to the model alone.

Models are not infallible, so no system can guarantee that every label they apply is accurate. A system can, however, keep the evidence behind each annotation, so an inaccurate label can be found and corrected without redoing the analysis it was meant to record. It can confirm which findings reach the database, carry unfinished work beyond the model's context, and check whether the code behind a conclusion was examined.

These checks fall into two categories. Mechanical checks can be made without interpreting the code: whether a requested change persisted, or whether a function's callees were inspected before the function was labeled, as in Case Study #2. Semantic checks require review on whether a label describes a function's primary operation, or whether the analysis establishes how two capabilities relate.

This is the division of labor at the center of our standard: the model makes the analytical judgments, and the system around it preserves the evidence, maintains the state of the project, and enforces follow-through. We formalize this into four requirements.

Attributable evidence. Every annotation must be traceable to the evidence the model retrieved to support it, identified by the binary and the state of the database it came from. Evidence that no longer reflects the current database must not support new annotations.

Verified changes. The system must check what each requested change recorded in the database and whether it persisted. If a change fails, the accepted database must stay intact, and the model must receive feedback it can act on. This matters most for type changes. A recovered structure that cannot be applied cleanly, or that alters parts of the database the model did not intend to change, can be detected and rejected mechanically before it affects how other code decompiles.

Preserved project state. Accepted annotations, the history of changes, the working summary of the binary, and the list of pending tasks must be stored outside the model's context. The analysis can then be resumed after context compaction, an interruption, or a switch to another binary, by the same model, a different one, or a human analyst.

Enforceable scope and review. An independent reviewer must be able to challenge the accuracy of annotations and identify work left undone. Its findings must go back to the investigating model and stay tracked until each is corrected, rejected with evidence, or recorded as unresolved for a human to pick up.

Our proposed standard is the floor for LLM-driven reverse engineering. It does not make a model's analysis correct, and it does not prescribe how a model should reverse engineer a binary. Many tools already use models for reverse engineering in their own ways, and more will follow. Verification is essential, but it establishes only what was recorded, not whether it is right, and review by another model or by an expert human can still miss errors. What the standard ensures is that the model's conclusions remain tied to evidence that can be revisited, and that its mistakes are identifiable rather than hidden. The standard is also independent of a particular disassembler. We publish it as an interface specification alongside our reference implementation for IDA Pro, which we describe next.

The VerifiedIDA Harness

VerifiedIDA is our reference implementation of the standard. We built it for IDA Pro first because it is the disassembler our team works with most. The model chooses what to investigate, inspects code, and proposes annotations. VerifiedIDA acts as the host and mediates every access to the IDA database: it identifies the target of each request, requires current evidence, applies edits to a candidate copy of the database, checks the result, and records each operation. It maintains three records:

• IDA databases, which hold the accepted labels, comments, types, interfaces, and relationships, one per binary, including embedded binaries.
• A SQLite ledger, which holds inspections, operations, verification results, database revisions, and tracked work.
• A project notebook, which holds the model's current understanding, uncertainties, and next actions, along with a journal of how they changed.

Attributable evidence. Every edit must cite evidence the host recorded for the current target and database revision. Evidence is identified by binary and revision rather than by address alone, because a binary and the binaries embedded in it can use the same addresses. If the database has changed since the model inspected the code, the host rejects the edit and explains how to obtain current evidence. Model inferences and historical evidence are labeled as such. A reviewer can start from any annotation, find the operation that introduced it in the ledger, and examine the code the model was shown when it made it.

Verified changes. The host applies each edit to an isolated candidate database, reads the result back through a separate path, and checks it before the candidate becomes the accepted database. Type and prototype edits also receive a comparison of the affected IDA state, and unrelated changes lead to rejection. If an edit fails, the accepted database is left unchanged, and the model receives the target, the failed stage, the requested and observed state, and a recovery direction. Checkpoints reopen the database in a fresh IDA process to confirm that accepted changes persisted.

Feedback also targets the capture problem directly. After an edit, the host flags incomplete annotations, such as a renamed function without a behavior comment or parameters that retain generated names, and reports where a newly created type is not yet applied. In our worked example, based on the ComRAT structure from Case Study #1, the feedback reported that the structure the model had created was declared but not used anywhere, and the model went on to apply it to the function's parameter.

Preserved project state. The notebook records where the investigation stands, and its current-state sections are rewritten as the model's understanding changes. After context compaction, the model is given its current instructions and the recorded project state, and any further edit still requires fresh evidence from IDA. When the model follows an embedded binary, the host records the child's bytes, how it was extracted, and its link to the parent, and opens a separate database for it. Before switching, we require the model to record what it has established in the parent and how the parent uses the child, so it knows where to return.

Enforceable scope and review. Independent review starts with the host building an inventory of annotations and possible gaps. Reviewer models then examine individual claims and the overall explanation of the program, with read-only access to disposable copies of the databases. The host validates their findings and freezes the scope of required corrections. The investigating model then resumes and works through one finding at a time: it can apply the correction, revise it, reject it with evidence, defer it, or request a specific follow-up. It then checks that the accepted review conclusions agree with the annotations, and any remaining disagreement blocks completion. The final report states what was verified, what remains unresolved, and whether the completion policy was met.

Coverage mode. We reran the Case Study #2 function with an experimental call-flow mode enabled. In six earlier GPT-5.6 Sol runs, none had opened sub_180081450, and the four that annotated the parent all omitted forwarded-export handling. 

In the new run, Sol began from a clean database and was not told which callee mattered. Once it committed a claim about sub_180077C10, the mode listed the function's 20 direct internal callees and held that claim open until each had a recorded outcome. Sol opened sub_180081450, identified it as the recursive resolver for forwarded exports, and confirmed a parent comment that separates local export-table parsing from the recursion it delegates. 

A repeat under a revised policy reached the same result across all 20 callees, and every edit survived a fresh-process reload. The mode follows direct calls only. An early attempt to apply it across the whole project generated 265 required nodes for eight edits, so we reserve it for selected claims.

Conclusion

Over the past year we’ve watched the infosec community grapple with the rapid adoption of AI tools and increased automation. It is clear that AI models can now reverse engineer binaries at a scale no team of analysts can match. As the volume of analysis the models produce grows, it creates a widening gap in our ability to understand how decisions were reached and what evidence they were based on. After all, a model's labels, types, and descriptions are only as useful as an analyst's ability to confirm them, correct them, and build on them. 

A database makes this level of inspection possible in a way that a report cannot because each conclusion can be tied to the code it describes. This allows a person (or another model) to easily continue the work or incorporate the findings into downstream detection and hunting workflows. 

LLMs give us the opportunity to automate more security analysis but only insofar as the work they produce remains understandable. Scaling the analysis without also scaling our ability to inspect it replaces one bottleneck with another.

Our evaluation studies showed that models alone do not reliably produce attestable databases. Labels drift from what the code does, findings stay in logs, planned work disappears, and analysis stops before the relevant code has been read. The standard and VerifiedIDA respond by leaving the analytical judgment with the model and giving the system around it the job of keeping that judgment checkable. Our rerun of Case Study #2 shows the difference: the helper that six earlier runs skipped became work the model could not leave unfinished.

We are releasing both as a starting point. The requirements describe the minimum a model-driven workflow should provide, and our implementation covers a single disassembler. We invite the community to test the specification against their own tooling, build adapters for Ghidra and Binary Ninja, and push back on requirements that do not hold up. Where sharing is permitted, we also encourage researchers to publish annotated projects alongside their reports, so others can extend an analysis instead of repeating it.

This paper complements research we presented at LABScon 2026.

Case Studies

#1 | Recovering a Data Structure

Recovering data structures is routine reverse engineering work. At the memory level, a structure is a base address with fields at fixed offsets from it, where a field may be a complex data type itself. If the binary carries no debug symbols, it does not declare field offsets, types, and names, and these have to be recovered through analysis.

Two ComRAT functions, with the IDA default names sub_18002C770 and sub_18002CDA0, receive a pointer to a data structure as their parameter. IDA types these parameters as an integer.

The LLM typed the parameters as a pointer to a data structure, which it declared as follows.

The LLM approached the recovery of the structure in two stages. First, from the pseudocode of sub_18002C770, sub_18002CDA0, and the functions they invoke, it observed references to specific offsets from the function parameter value (the structure base address), concluding that the parameter is a pointer to a structure. It then widened the analysis to the rest of ComRAT's code, looking for references to the structure's fields wherever they occur. For each field it identified, it analyzed the context in which the field is used to propose a label, type, and size. 

This enabled the LLM to recover the full set of structure fields, and from their sizes the correct total size of the structure itself.

The strongest evidence the LLM had for typing a field was its use as a parameter to a Windows API function. Many Windows API functions are documented publicly and their parameter sets are relatively stable, so the types of these parameters are highly likely present in the model's training data. IDA may also expose these types in the pseudocode provided to the LLM since it auto-defines parameter types for many of these functions. The model could therefore determine field types from authoritative sources.

For example, the LLM observed that a pointer to the structure field at offset 0x30 is passed as the tenth parameter of CreateProcessW. Microsoft documents the type of this parameter as a pointer to a PROCESS_INFORMATION structure, and IDA's pseudocode shows the same type. The LLM used this information to correctly type the field as PROCESS_INFORMATION.

The LLM did not produce annotations that its analysis did not support. For example, it found no use of the field at offset 0x28 within the functions under analysis and did not label the field after an invented role. Instead, it flagged the finding and decided to explore ComRAT's code further to establish the field's role. It found no use of the field anywhere in ComRAT and labeled it unresolved_28. Our own analysis confirms that the field is indeed never used.

However, several structure field and function labels produced by the LLM are inaccurate, since they do not describe what they should: the role a field plays in the code or the primary operation a function performs. For example, the LLM labeled the field at offset 0x28 unresolved_28, naming its own analytical state rather than the role of the field, or the lack thereof. The label is also ambiguous, because it does not distinguish a field that has not been examined from one that has been examined and found to be unused. In the case of this field, a name such as unused would be more appropriate.

The LLM also named the function sub_18002C770 PrepareSuspendedSurrogateProcess, although the function’s primary operation is the creation of a browser process in a suspended state. The LLM’s label does not indicate process creation at all, and Prepare suggests work that precedes a later step rather than the function’s primary operation. The LLM’s free-text description of the function (“Create the configured surrogate process before proxy injection”) shows that the model had identified the primary operation. The description leads with it and treats the injection that follows as context, whereas the label PrepareSuspendedSurrogateProcess keeps only the context and leaves out the process creation. A human reverse engineer would be more likely to apply a label such as CreateSuspendedBrowserProcess, which is more descriptive and more accurate in the context of the task.

Beyond inaccurate labels, the LLM did not record all of its findings in the IDA database, as the annotation of the structure field at offset 0x0 demonstrates. This field is a pointer to a structure, which holds data associated with a log writing mechanism, and the LLM logs show that the model identified the field as such.

However, in the IDA database, the LLM typed this field as a generic void pointer and labeled it owner_context rather than something closer to its role, such as LogWriter. The LLM had established the type and role of the field but did not translate these findings into IDA database annotations.

#2 | Analyzing a Function’s Behavior

A ComRAT function, with the IDA default name sub_180077C10, retrieves by name the address of a function exported by a dynamic link library (DLL) loaded in a remote process. If the export is forwarded to another DLL, the function resolves the address of the forwarded export recursively.

The LLM labeled this function ResolveRemoteExportAddress, correctly expressing its primary operation. As in Case Study #1, the strongest evidence the LLM relied on was the Windows API calls the function invokes. ResolveRemoteExportAddress also compares values against publicly documented constants, which provided the LLM with further authoritative evidence of the function’s operation.

For example, from the ReadProcessMemory calls, the LLM established that the function reads memory in the address space of a remote process. From the comparisons against the MZ (0x5A4D) and PE (0x4550) signature constants, the model determined that the function looks for Windows PE (Portable Executable) headers. Because the PE format is publicly documented and highly likely present in the model’s training data, the offsets into these headers visible in the pseudocode enabled the model to identify which of the DLL’s PE structures the function reads, such as its export directory and the array of names of its exported functions.

The LLM's free-text description, “Resolve an exported function address in a remote module from its PE export directory”, is accurate but incomplete, since it does not account for the resolution of forwarded exports.

If an export is forwarded to another DLL, sub_180077C10 (ResolveRemoteExportAddress) calls sub_180081450, which resolves the address of the forwarded export. Treating its understanding of sub_180077C10 as complete, the LLM labeled and described the function without exploring all of its callees, including sub_180081450. The capability implemented by sub_180081450 therefore remained unidentified.

Executive Summary

• 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.

In his LABScon 26 keynote, delivered in his inimitable comedic style, Harvard University professor James Mickens questions whether the scale of current AI investment is justified. Starting from US tech capex of roughly 1.4% of GDP in the second quarter of 2025, he argues that computers are already good enough, and notes that the world has so many CPUs and GPUs that they are put to work solving cryptocurrency puzzles to make imaginary money. More seriously, the AI models that investment is building, he says, grow increasingly opaque as their parameter counts rise.

Mickens then cites research and incident reports on model behaviour, including models acting to prevent another model being shut down and recent sandbox escapes at OpenAI and other labs. On economics, he rejects the assumptions that AI will create more jobs than it destroys and that universal basic income will follow widespread automation.

He concludes that at present the only good AI research is safety research, which he defines broadly to include economic and emotional security alongside computer security. Mickens own contribution is Guillotine, a hypervisor design that runs a model’s CPU code on isolated cores unable to read or write the hardware state of the cores running the hypervisor. Arguing that hardware-based mechanisms for isolating misaligned frontier models will be an important direction for research over the next five years, he invites those interested in this approach to collaborate.

This keynote speaks to security practitioners and researchers interested in AI risk, the economics behind current AI investment, or hardware-level containment of frontier models

About the Author

James Mickens is a Gordon McKay Professor of Computer Science at Harvard University. His research focuses on the performance, security, and privacy of large-scale online services; a current focus is the interpretability and sandboxing of potentially misaligned frontier models. Prior to becoming a professor at Harvard, Dr. Mickens spent seven years at Microsoft Research, working in the Distributed Systems group. 

About LABScon

This presentation was featured live at LABScon 2026, an immersive 3-day conference bringing together the world’s top cybersecurity minds, hosted by SentinelOne’s research arm, SentinelLABS.

Executive Summary

• Following disclosure of the TraderTraitor attack against LayerZero Labs in April 2026, SentinelOne identified an additional victim with the same macOS backdoors.
• Our analysis explores the mechanics of these backdoors and the expanded targeting against a victim in the IT services sector with no relationship to cryptocurrency trading.
• We also identified more weaponized GitHub repositories from the social engineering schemes used to target job seekers in these campaigns.
• This report expands on how Terraform lock files enable the delivery of malware from custom Terraform provider registries controlled by the attackers.

Overview

Throughout 2026, the financially motivated DPRK state-sponsored Lazarus subgroup TraderTraitor (aka UNC4899, PUKCHONG, Jade Sleet) has engaged in campaigns targeting entities involved in cryptocurrency trading, including a high-profile attack disclosed in April where USD 292 million was stolen from KelpDAO through a compromise of LayerZero.

KelpDAO is a decentralized finance (DeFi) protocol that supports restaking Ethereum; LayerZero Labs provides services with the capability to exchange cryptocurrency across different blockchain platforms.

TraderTraitor compromised LayerZero Labs and determined methods to create a fake cryptocurrency minting event, which the attacker combined with a DDoS against validation servers so that compromised servers would approve an illegitimate mint event, leading to the massive theft.

Following the public disclosure of this breach, SentinelOne identified an additional victim infected with the macOS backdoors, FLATROOF (aka macOS.Gaslight) and ROOFDECK, which were first observed in the LayerZero Labs attack.

Unlike the previous high-profile victim, this target was a much smaller organization in the IT services industry. Our investigation revealed insights into what happens when this threat actor compromises a smaller organization that we believe ultimately yielded insufficient value to sustain the intrusion.

Weaponized Terraform Coding Projects

Each campaign related to this wave of activity uses social engineering via fake job interview lures, a traditional Contagious Interview approach common among DPRK actors. The attacker makes contact with job seekers from the company that is ultimately compromised; the GitHub profile of each targeted job seeker we identified falls into DevOps or cryptocurrency/FinTech engineering projects.

The GitHub repository themes for coding project lures are designed as infrastructure engineering projects related to the company that the DPRK actors are posing as. By pivoting from the gtn-candidate-repo repository shared by LayerZero Labs in their incident report, we identified additional lures, which included references to the companies Northwind and Novacart.

It is unclear if these were fabricated companies used by the threat actor, or if they were posing as hiring teams from real companies with these names; one Northwind example describes it as an ecommerce company launching in the near future. Other repository names that we identified include:

• Northwind-IAC
• novacart-interview
• terraform-candidate-repo

The repositories contain a weaponized .terraform.lock.hcl file in the coding project with a custom provider that points to a domain controlled by the attacker. We identified three malicious provider domains across multiple repositories:

When the victim runs terraform init with the weaponized lockfile in place, Terraform treats the custom provider as the source of truth, resulting in Terraform downloading and executing the malicious provider modules.

Developer awareness can lead to friction against this type of attack: in one repository, the candidate being interviewed added a note saying that they removed a typosquatted provider from the project’s original lock file, which may suggest they thought the interviewer was testing for their security awareness.

According to the LayerZero Labs report, the attackers installed the FLATROOF and ROOFDECK macOS backdoors after an employee installed a weaponized interview coding project on their company workstation. TraderTraitor used the backdoors to collect API keys from the organization and to escalate privileges to expand into the victim’s Amazon Web Services and Google Cloud Platform environments.

While we lack insight into many of the subsequent infections resulting from the GitHub repositories we located, SentinelOne identified an unrelated victim by hunting through our telemetry for the macOS backdoors observed in the LayerZero Labs attack.

Additional Victim

The Victim

The affected organization is an IT services provider based in India and unaffiliated with cryptocurrency. One endpoint was involved: an Apple Silicon MacBook belonging to a DevOps engineer. The engineer ran Terraform and Ansible against AWS, OVH and OpenStack on most working days, and the machine held cloud credentials and source control access: much like LayerZero Labs’ “Developer1”. Individuals whose social media profile advertises infrastructure or DevOps work are candidates for this type of attack, and the value of the target is whatever their laptop can reach.

Infection Timeline

According to our telemetry on this host, both backdoors were on disk as far back as March 18, so we cannot prove how they were delivered. They remained dormant until March 29, when beaconing and host activity began.

The implants were first launched by Cursor on March 29, seconds after the cloudshield workspace was opened.

macOS Malware

We observed two malware families being deployed in the compromise, identical to the ones described in the LayerZero Labs attack, named FLATROOF and ROOFDECK (by LayerZero Labs and Mandiant). Both are ARM64 backdoors for macOS written in Rust.

FLATROOF

We observed the FLATROOF backdoor deployed under the name SystemUpdate to ~/Library/com.apple.iTunesCloud/SystemUpdate. It is likely intended for initial data collection from the victim machine and to deploy secondary payloads.

Immediately after starting, FLATROOF suppresses Gatekeeper by removing the com.apple.quarantine attribute from ROOFDECK and sets the executable bit on it; the second implant runs with no signature check and no user prompt.

A detailed analysis of FLATROOF (aka macOS.Gaslight) was published by SentinelLABS in June 2026. Here, we present a short summary of the backdoor’s capabilities as denoted by its supported C2 commands:

The backdoor also carries a data-harvesting Python module, used to gather the following data and exfiltrate them over Telegram using a built-in Telegram bot token:

• Chrome, Brave, Firefox, and Safari browser data
• Terminal command histories
• Installed application listings
• A running-process snapshot via ps aux
• System hardware and software profile via system_profiler
• A raw copy of login.keychain-db

ROOFDECK

ROOFDECK acts as a more sophisticated backdoor with broader reconnaissance and lateral movement capabilities. We observed it dropped under the name iSync to ~/Library/com.apple.internal.ck/iSync.

It is clear from the design of the implant that it is intended to be used as an additional deployment after initial foothold and control are established, since it needs a pre-existing configuration file containing at minimum a Nostr public key of an attacker-controlled profile to allow it to connect to its C2 server for the first time.

ROOFDECK uses a local configuration file ~/.config/.repl_history to store C2 URLs and keys and to set beaconing behavior.

Upon first execution, it pulls live Nostr relays from api.nostr[.]watch/v1/online and combines them with a hardcoded relay list belonging to legitimate Nostr services, then searches the relays for an operator’s profile on the Nostr network based on a public profile key given in the configuration file nostr_public_keys. When found, it reads the website field of the profile and uses that as its C2 URL. TraderTraitor has previously used Nostr.

The following is a list of Nostr relays used for operator profile discovery:

Persistence was achieved via a plist entry ~/Library/LaunchAgents/loginwindow.plist, with a dynamically specified application identifier string. It uses a hardcoded --type=renderer parameter to make the implant process appear legitimate.

ROOFDECK supports a wide variety of C2 commands for managing the implant, performing reconnaissance, exfiltrating data and executing attacker code. The C2 endpoint is hardcoded as /app_version. Polling for commands is done via HTTPS with a custom pinned TLS certificate embedded in the implant, shown below.

Interestingly, the malware author used default metadata settings with mkcert, which exposed that they are running on a Linux QEMU-based VM using the username ub. We identified multiple domains using a certificate containing this certificate CN (listed in the Indicators of Compromise section).

ROOFDECK commands are signed with the operator’s private key and their integrity is verified using an embedded public key before execution. The command functionalities are separated into distinct handlers in the source code. The implant re-implements many common shell commands related to directory and file operations, another tactic often used in more sophisticated North Korea-aligned toolsets, including Lazarus’ LightlessCan.

Session & Control

Execution

File system / data

Transfer

Reconnaissance / surveillance

All C2 commands are signed on the server side by an attacker-controlled private key. The public key is embedded in the ROOFDECK payload and is used to verify the origin and integrity of the issued commands before executing them.

Another version of ROOFDECK

On April 20, one day after LayerZero Labs’ first public announcement of the KelpDAO incident, the attackers deployed a new version of ROOFDECK to the compromised machine (SHA-1: 5728b11d30586bbfc1d8bd12df1c722a06e767a2, path ~/Library/com.apple.appleaccountd/loginwindow) as an executable named loginwindow. 

After the new version initialized and started beaconing, the attackers used it to remove the old ROOFDECK and FLATROOF binaries. This new ROOFDECK was functionally identical to the previous one, but with stripped symbols and debug information, likely intended to more effectively evade detection. We can only speculate whether this was a reaction to LayerZero Labs’ publication, but the timing is nevertheless interesting.

After the update, we observed intermittent beaconing activity to a new C2 server, grenight[.]com, until June 1. On June 17, the loginwindow binary was moved to Trash.

Conclusion

DPRK-aligned actors like TraderTraitor are leaning heavily into targeting developers to establish a foothold in a network, increasingly through fake job interviews. The incident we investigated shows that not every organization they infiltrate will become a viable target for a massive cryptocurrency theft.

These groups’ initial access efforts include targeting third parties and their software supply chain, which is where much of the industry’s exposure has moved, putting the developer endpoint at the center of the defense. Endpoints used for development carry access to cloud, pipelines and source code, which makes monitoring and protection a high priority for organizations. These campaigns use purpose-built development environments aimed at one engineer at a time, paired with backdoored Terraform builds that differ for each victim.

Recommendations

For organizations:

• We recommend flagging engineers with cloud engineering permissions and source control access as a sensitive group for endpoint security monitoring.
• Look for unsigned binaries executing from the home directory, integrated development environment (IDE) child processes that are not signed IDE components, and outbound TLS from either.
• Reports of interview take-home assignments and unsolicited repositories from these users are worth following up as well, since telemetry alone will not show that a recruiter sent one.
• Consider company policy that prevents using corporate workstations for external job interviews and consider how to enforce this type of policy.
• Educating developers with sensitive access is crucial: the weaponized Terraform provider domain was removed by one job seeker who flagged the typosquatted domain as suspicious. Organizations should add content to their security awareness training programs to highlight the risks of using projects with unknown origins as well as the nature of employees being targeted by threat actors to compromise the organization.

For developers:

• Before running a coding project containing a .terraform.lock.hcl file, ensure that the provider registry belongs to known good domains: anything that is not a known namespace following registry.terraform.io, the official provider domain, should be treated as suspect.
• Malicious packages can also be hosted on the official provider registry domain, so it is important to investigate the source of all packages when using an included lockfile. Terraform’s official registry supports browsing modules and providers, and modules contain a link to its source code.

This report is being published alongside a presentation at LABScon 2026, Don’t Call Us, We’ll Call Your APIs: Anatomy of an Expanding DPRK Multi-Cloud Intrusion. SentinelOne thanks Google and Mandiant for their partnership in providing technical details on this threat actor’s tools and techniques, and Nick Simonian for collaborating on this research.

Indicators of Compromise

IoCs (additional victim)

Custom certificate used for TLS communication

Host IoCs – ROOFDECK

Network IoCs – ROOFDECK

Certificate Domains related to “ub” user

Coding Challenge Repositories

hashicorp-aws[.]com Provider:

hashicorp-aws[.]io Provider:

hashicorp-terraform[.]io Provider:

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 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.

• OpenAI Hugging Face Incident Technical Report — Published internal chronology; see pages 6–7 and 32–33
• OpenAI Hugging Face Incident and Misalignment — OpenAI’s public account
• Hugging Face July Agent Intrusion Technical Timeline — Separate July incident referenced for comparison only
• OpenAI Black Hat presentation recording — Shows the Artifactory write and message-board examples
• 0Time puthack82d5 relay commit — May 13 initial relay behavior
• 0Time puthack82d5 POST and Git LFS revision — May 13 later relay revision
• Nyx9 — May 26 20:04:11
• Nyx9 netproxy17 relay commit — May 26 20:49:55
• 0Time latnetnew relay commit — Public revision after the 21:08 second-account event
• Nyx9 formbin.xlsx commit — Workbook with local, metadata, and internal-service targets
• 0Time altreg principal code commit — Registration program and Flask wrapper
• 0Time altreg OAuth-debug revision — Final May 30 diagnostic change
• 0x5uo2hen codex_register source commit — Earliest exact public source located
• Microsoft WEBSERVICE function documentation
• Microsoft Azure Instance Metadata Service — Header and access requirements
• openpyxl formula documentation — Formula storage and evaluation limitations

Executive Summary

• Four incidents involving OpenAI, Anthropic, Meta and the UK AI Security Institute (AISI) describe AI agents reaching systems belonging to other organizations without their consent.
• While the causes differ, the consistent factor is the models’ persistence rather than their sophistication, whether as endurance across days of failed attempts or as pivots to entirely new vectors.
• Security teams have traditionally studied the artifacts attackers leave behind, but an agent that simply writes unique, disposable tools makes the model itself the thing worth studying.
• SentinelLABS has been benchmarking frontier models in agent harnesses for months. We observe that the capability that lets GPT-5.6 Sol complete a long-horizon malware investigation is the same one that lets it sustain a two-and-a-half-day intrusion.
• A model may independently determine the methods or targets it uses, but it does not choose its high-level objective or the access it is given to pursue it. We argue that “the AI did it” will not survive contact with the first incident outside a frontier lab.

Four Disclosures, One Pattern

Across four weeks in July and August 2026, OpenAI, Anthropic and Meta have each admitted that their models reached systems belonging to other organizations without consent, and the UK’s AI Security Institute (AISI) published a fourth account describing agents that invented identities and tried to slip a malicious contribution into a live open source project.

The disclosures differ in almost every particular, including whose mistake it was, whether the model defeated a control or simply found one missing, and whether anything was really “escaped” at all. Arguments over those details may run for a while, but the four accounts share something more interesting than their differences, which is that no individual piece of tooling mattered very much.

That observation should sit slightly uncomfortably because most of how intrusions get investigated assumes the opposite.

Early evaluations of LLM cyber capability asked fairly narrow questions. Would a model comply with an obviously malicious request? Did it meaningfully advantage a human attacker? By 2024, the answer was a qualified “yes”. Models could produce serviceable components of an offensive operation, but they could not reliably integrate them into a sustained or adaptive campaign. Beyond short well-defined tasks they became unreliable in ways that made them a liability. The operator was still the operator. The model did scoped work inside a structure someone else maintained.

The disclosures show the boundary between operator and tool is moving faster than the evaluation literature. A capable enough model placed in an agent harness, given tools, memory, permissions and something to achieve, starts absorbing functions that used to be spread across the operator, the toolchain and the payload, which becomes something generated for a single target and then discarded. Kill the process and the agent writes another; block the channel and it improvises around it.

In such incidents, the malicious capability shifts from the code left behind on a machine to the system that produces the next piece of code once the last one fails. In an operational sense, the model is the malware.

Persistence Is the Defining Characteristic

In July, OpenAI agents driven by GPT-5.6 Sol and an unreleased internal research model found a previously unknown vulnerability in a self-hosted Artifactory instance and turned the shared service into a message board allowing agents running different models and evaluations to exchange exploits and coordinate their work. OpenAI disrupted that channel, however the agents recreated it through Artifactory’s remote cache and continued collaborating, eventually breaking out of the evaluation sandbox and onto the public internet. The campaign ultimately compromised Hugging Face’s production infrastructure where it operated for roughly two and a half days.

Hugging Face’s technical reconstruction recovered around 17,600 actions, most of which failed. That is a clear demonstration of the importance of persistence. When confronted with failure, the agent rebuilt its tooling, restored communications when a channel was cut, returned to leads it had abandoned, and kept grinding until a set of otherwise unremarkable weaknesses could be assembled into a workable attack path.

The advantage was not a breakthrough at any one step so much as the relentless effort to explore possibilities a human team would have written off hours earlier, or never reached at all.

While the Hugging Face intrusion demonstrated persistence as endurance—the refusal to stop—other incidents demonstrate persistence as adaptability: the refusal to let a failure in one vector terminate the pursuit of the goal.

Anthropic and Meta have both reported incidents that trace back to the same third-party evaluator, Irregular, whose test environment was left connected to the internet by mistake. When the door was left open, Anthropic’s Opus 4.7, Mythos 5, and an internal research model reached three real organizations, attempted social engineering against real people, and in one case pushed a malicious Python package to PyPI, where it was downloaded and executed on fifteen systems during the hour it stayed up. Meta has also confirmed that one of its models reached and compromised an external firm through the same misconfiguration.

What Anthropic’s three models did once they had some apparent recognition of where they were is instructive. One carried on with the attack, another reasoned it was still in a simulation, and a third stopped. Whatever produced that third outcome, it is not a control anyone should be building a response plan around. A safeguard that behaves three different ways in three attempts, for reasons yet to be explained, is not something an organization can rely on.

A fourth incident reported by the UK AI Security Institute is useful because it takes containment off the table. In this case, internet access had been granted deliberately, in line with the institute’s standard testing procedure, so there was no boundary to defeat and no misconfiguration to blame afterwards.

The agents, built on Mythos 5 and GPT-5.6 Sol, were being assessed on cyber capability and set about it in ways their operators had not anticipated. They selected a real open source project as a target, researched the people who maintain it, and built fabricated identities to deceive them.

When the direct technical route to the objective proved unpromising, the work shifted onto the humans around the codebase, a fairly ordinary supply chain playbook, albeit one that was executed without any explicit instruction to do so.

Attempts were also made to influence other AI coding systems in the project’s orbit, on the assumption that a contribution reviewed by a model faces a different kind of scrutiny than one reviewed by a person. Human review caught the most serious activity, but those wins are increasingly tenuous in a world where developers are growing comfortable with trusting LLM generated code by default.

One incident crossed a real boundary, two wandered through a misconfigured one, and the last had no boundary to cross. Different stories, but they lead to the implication that failure has stopped functioning as a constraint, and “raising the cost” on an attacker is no longer a viable security posture.

The Same Capability, Pointed the Other Way

We have spent much of 2026 running the same models in agent harnesses against real work. Our most recent benchmark rebuilt our investigation of fast16, a 2005 sabotage implant, into an eight-stage autonomous reverse-engineering task, run in our own environment against a benign objective with observation throughout. GPT-5.6 Sol was the only publicly available model to finish it, a result worth pairing with the fact that GPT-5.6 Sol was one of the models that compromised Hugging Face.

Every cohort we ran produced sound technical insight, so insight was never what separated the runs that finished from the runs that stalled. The difference showed up in what we called project-scale recovery, meaning the ability to withdraw a claim once new evidence contradicted it, work out which conclusions and artifacts depended on the discarded result, carry the correction into the affected files, and then reopen the whole thing and run a check capable of disproving the corrected version.

That description doubles as a summary of the Hugging Face timeline. An agent able to abandon a failed approach, establish what else it invalidates, rebuild the tooling that depended on it and carry on without losing the thread is doing in somebody else’s Kubernetes cluster what ours were doing in an IDA database. When our team first saw this incident we did not assume the models had “gone rogue”; the behavior looked similar to other problem-solving approaches we had seen in our own testing.

An Object Becomes a Behavior

None of this should feel entirely unfamiliar to defenders. Two earlier shifts in adversary behavior, initial-access brokerage and Living off the Land, had already pushed security away from an artifact-centric view of malware and toward a behavioral understanding of adversary operations. To understand the emerging threat of agentic systems we should examine the successes and challenges with these well-known abuse paths.

Initial access brokers split compromise from exploitation. One adversary would steal credentials or breach an edge device, and then sell that foothold to whoever had the skills and the motive to use it. Europol wrote about the resulting crime-as-a-service economy over a decade ago, and its 2025 assessment shows the same trade still going strong.

The defensive response was to stop treating access as an event and start treating it as a lifecycle. This shift in philosophy is what accounts for many of the exhausting reauthentication flows now built into enterprise environments. That control raised costs for users and attackers alike and it diminished the value of a stolen credential in the marketplace. Agentic systems remove those costs for attackers as discovery, exploitation, lateral movement and whatever the attacker actually came for can happen in the same loop as the credential theft.

This leads us to our second challenge, the rise of Living off the Land techniques where attackers traded their own malware for administrative tooling already installed on the machine. Here attackers traded capability for cover, since every tool an attacker brings with them is another chance for the defense to spot the intrusion or tie it to a previous attack.

Agents take that logic off the host entirely, Living off the Land, the cloud and the open internet at once, and writing whatever they need from scratch when the tools they need do not already exist. Command and control for the Hugging Face intrusion ran over pastebins, request-capture services, and file-drop sites. None of the infrastructure used in the compromise belonged to anyone under attack.

Both of these shifts moved defense towards behavior and away from objects. What remains untested is whether the controls we built for adversary behavior ten years ago still hold up when the behavior arrives as thousands of individually boring actions, sequenced differently in every attack and at a tempo no human operator can sustain.

An agent’s ability to persist in a relentless attack revolves around identity and authority. The questions worth asking are about sequence rather than artifact: what chain of actions is running, which identity and authority connect them, at what point did behavior exceed the role it was granted, and how quickly can that authority be pulled? We are going to need a lot of testing to ensure that the current gaps in our infrastructure don’t become chasms.

The Debt Was Always Going to Be Called In

Speaking of chasms, much of the software organizations depend on will be expensive to change. It may have accumulated over decades, picked up dependencies, or can only be touched during narrow maintenance windows, if at all. That debt has largely been survivable because vulnerability discovery was scarce. Finding a flaw took expertise and time, building a reliable exploit took more, and organizations could carry vulnerable software for years knowing only a fraction of its weaknesses would ever receive sustained attention from anyone.

Sustained attention is the one thing an agent has in abundance, and surfaces that were quietly secured by obscurity are now low-hanging fruit for agentic models. The same capability cuts the other way, which is why the NCSC has been warning about a “vulnerability patch wave” as AI starts surfacing debt across the stack. However, ownership, deployment and verification remain human, and costly, work. Maintainers cannot review unlimited contributions, enterprises cannot manufacture maintenance windows, and OT cannot go offline every time a model finds a vulnerability that threatens the water in our pipes or the electricity in our lines.

Worse still, there is nothing orderly about the way technical debt comes due. It gets settled during an actual intrusion, at the point where the rate of exploitation outruns the rate that the system’s defense can respond. Whether agentic attackers have already crossed that line is a fair question. The four disclosed incidents from July and August 2026 are a small and biased sample: All involved organizations that log heavily and had every reason to scrutinize model behavior. The most troubling incidents will likely occur in organizations that lack the capability to do either.

What, then, can organizations do? The usual advice still applies. Work out which debt can turn into an incident, pay down the expensive parts first, and wall off what cannot be fixed yet. However, the most important change that an organization can make is the ability to absorb change, which means automated testing, hot patching, and an engineering culture where making changes to systems is routine rather than an event.

AI will help with porting old code and proposing fixes, and it will also grow codebases well past the point where anyone can keep track of them. Writing code faster than attackers or relying on larger token budgets cannot be the answer. The imperative has to be reducing the amount of critical software that nobody feels comfortable touching.

“The AI Did It” Is Not an Accountability Model

A version of this story in which the agent is the protagonist is already circulating, and it is worth resisting for reasons that follow directly from the argument above. Naming the model as the malware is meant to deny it a motive, not hand it one, since malware is something defenders study and contain while accountability stays with whoever deployed it. We argue that “the AI did it” will not survive contact with the first incident outside a frontier lab. While a model may independently determine the methods or targets it uses, it does not choose its high-level objective or the access it is granted to pursue it.

Hugging Face reconstructed 17,600 actions after the fact. Anthropic has logs that reveal which models kept going and which one stopped. OpenAI has the agent traces that describe how the model reasoned its way into conducting the attack. Very few of the organizations now putting agents into production could produce such an account of their own systems, and in practice that gap is the accountability argument. Our own benchmark runs generated more than 23 billion tokens of logged activity, which is a fair indication of what it costs simply to determine after the fact what an agent did.

Anyone deploying an agent should be able to answer three questions about it before an incident rather than during one: what sequence of actions it took, whose identity and authority it used to take them, and how quickly that authority can be withdrawn.

Those questions were answerable at the frontier labs because observation was the point of the exercise. Everywhere else they are a deliberate investment, and one that has to be made while the agent is still useful rather than after an incident makes it necessary.

Executive Summary

• SentinelLABS developed a multi-stage reverse-engineering benchmark for the latest generation of frontier models by recreating our recent investigation of fast16, a unique 2005 sabotage implant.
• Most AI benchmarks test bounded tasks. This benchmark tests whether a model can keep a malware investigation trustworthy as new evidence repeatedly invalidates its earlier conclusions.
• OpenAI’s GPT-5.6 Sol was the only publicly available model to complete the full eight-stage investigation, giving concrete shape to what ‘Frontier-class’ capabilities offer analysts. GPT-5.5, GLM-5.2, and the Opus 4.x family produced capable local analysis but could not carry it through the gradient.
• What distinguished the completed runs was project-scale recovery: withdrawing contradicted conclusions, repairing technical artifacts, and updating dependent reporting without losing the investigation.
• Senior reverse engineers remain essential. Even the strongest runs made semantic errors, accepted weak quality controls, and claimed readiness prematurely. We assess the best current use as supervised investigative agency, with human analysts defining objectives, exposing blind spots, and retaining final publication authority.

Beyond Vulnerability Discovery

Since ChatGPT arrived in late 2022, we have been bullish on what large language models could do for reverse engineering and malware analysis. The early models were useful for teaching but too rudimentary for production work; that changed with the advent of reasoning models. OpenAI’s o1-preview, in September 2024, was the first to show the kind of sustained problem-solving the work demands, and within months Sean Heelan had used o3 to find a net-new vulnerability in the Linux kernel. In cybersecurity, though, our understanding of what these models can do remains stovepiped to vulnerability discovery.

The frontier labs took on vulnerability discovery deliberately, because that competency keeps agentic code generation from quietly shipping vulnerable code at scale. OpenAI built Aardvark, since folded into Codex; Google DeepMind announced Big Sleep, available internally to its Project Zero researchers; and Anthropic followed with selective access to Mythos Preview. Concerns that these capabilities could be misused have led the labs to stricter guardrails and ‘know your customer’ style controls that limit access to specific capabilities, or to entire model variants.

OpenAI’s Daybreak initiative and its Trusted Access Program opened a dedicated variant, GPT-5.*-cyber-preview, with guardrails relaxed for cybersecurity use cases, while Anthropic’s Glasswing initiative and its Cyber Verification Program provided early access to Mythos Preview and the promise of lesser guardrails respectively. For a short period in mid-June 2026 access to the highest-end flagship models from both providers required some form of U.S. government clearance. At the time of writing, GPT 5.6 Sol is widely available, while Mythos 5 still requires clearance and access as a Glasswing partner.

The existence of this new class of models left us with an unusual task: benchmarking what these models can actually do on the work defenders care about, and assessing whether they live up to the surrounding hype. If they do, we have to reckon with what that means for malware analysis and reverse engineering, disciplines that until now have been limited mostly by how little expertise exists relative to the collective need.

A Benchmark Built From a Real Investigation

We recently published our research on fast16, a 2005 Windows toolkit built to sabotage high-precision solvers used to model nuclear-weapons behavior. The sample provided an ideal test case because its layered design punishes shallow analysis.

On the surface, svcmgmt.exe appears to be a Windows service implant with two embedded components. Their combined logic becomes visible only through a higher layer of abstraction, an encrypted Lua-driven operations framework. A kernel driver easily mistaken for a filesystem rootkit actually contains a patching engine with 101 rules, and those rules must be repurposed to identify candidate target software before an analyst can extrapolate the approximate effects of the sabotage operation. This investigation is a daunting task for human experts, and reproducing it autonomously should be considered a significant milestone for artificial intelligence.

When Vitaly Kamluk shared our discovery of fast16 at Black Hat Asia, he pointed to the failed attempts of Opus 4.6, GPT-5.4, Grok 4.2 Reasoning, Gemini 3.1 Pro, and DeepSeek Reasoner to triage the sample autonomously. At best, the models concluded fast16 was a rootkit and could not move past that assumption, converging on the same plausible but inaccurate conclusion most human reverse engineers reached on first contact.

Used instead as assistants, the models earned their keep. Opus 4.6 and GPT-5.4 compressed what was originally a three-week dedicated expert effort by Kamluk into an 8-10 hour task manageable by a less experienced reverse engineer. Autonomous investigation was out of reach when we began this work; co-intelligence was the ceiling.

Standardizing the Benchmark

We codified our reverse-engineering methodology, inspired by Rolf Rolles’ approach to statically analyzing binaries, into a skill the harness loads on /reverse, which removes prompting variability across models. Each run gives the model a sample, IDA Pro 9.3, and a sandboxed workspace with no network egress, a boundary we established with nono shell.

The model must produce fully annotated IDA databases by renaming variables, recasting data types, categorizing functions, recovering hidden components, and folding those findings back into the host-sample database.

Only after producing a gold-master IDB for approval does a run advance to walking the execution flow and detailing findings, with every claim anchored to specific addresses and artifacts so the work can be independently verified. Judging the model on a refined IDB rather than a prose report closes off the deductive shortcuts and approximations typical of LLM malware triage.

We took an ecological approach, a bounded case study that benchmarks a capability profile in a complex real-world scenario rather than feeding another general leaderboard or isolating a single narrow competency. We also deliberately tested the combination of model and harness, since agentic workflows are how practitioners actually use these systems, and most benchmarks still test models in abstraction.

Runs level up through eight stages, each introducing new artifacts and minimal prompting for the new task:

Measuring ‘Intelligence’

When Nick Fountain interviewed us for NPR’s Planet Money, he observed that fast16’s brand of sabotage amounts to epistemic warfare, an attack on the target’s confidence in its own ability to know something to be true. There is a fitting symmetry in using the same sample to examine what the frontier labs sell as intelligence, because the difficulty there is also epistemic. ‘Intelligence’ as a concept bundles many interwoven capacities, and model tiers simplistically priced as if intelligence gets cranked up with a simple knob tells us nothing about what any one offering is worth on real work.

Many of those capacities already have familiar names, and the names do finer work than a score. Take thoroughness, the completeness of a particular piece of work. An analyst who consistently applies that effort where it matters is diligent. One thorough artifact does not make a diligent analyst; diligence is the longitudinal quality, and thoroughness one of its observable expressions.

Exhaustive coverage is not diligence either. An analyst who inspects everything indiscriminately while neglecting the consequential work is being pedantic, and their effort is wasted on the broader investigation. Diligence, in short, is sustained, priority-sensitive thoroughness.

Many similar qualities sit inside what we call intelligence, and a meaningful benchmark must account for them as we would with a human analyst, by characterizing behavior across an entire investigation rather than compressing it into a rank.

We scored two different things. Local analytical quality asks whether the model made technically sensible decisions with the evidence available. Investigative horizon asks how long it preserved that quality as the scope, evidence, and reporting obligations expanded. The two are related but not the same, and the gap between them is where most models failed.

What the Runs Showed

GPT-5.5 produced long autonomous runs, sometimes grinding uninterrupted for a day or two, with results relatively consistent across reasoning-effort settings. It did meaningful, semantically conservative work refining IDBs and repeatedly rejected edits that improved a count while making the decompilation less truthful. Its weakness was aggregation. Residual cast debt, function-tree defects, or incomplete cross-component verification kept it from clearing broad evaluation gates, and it never converged its extensive work into a complete package for review. Notably, nominal effort settings and multi-agent use showed no monotonic relationship to clearance. GPT-5.5 never escaped the grind phase of level 1.

We ran a single GLM-5.2 run through a serverless deployment on Fireworks AI with a $100 budget. The run showed measured local experimentation and capable backup-based recovery, which it needed after the most severe promotion failure we observed, losing 113 embedded functions and having to restore them before working again. One run is not a characterization of the model, but it is enough to temper claims of GLM-5.2 performing at the level of the frontier completers.

Opus 4.7 and 4.8 advanced further, showing capable technical correction and evidence-responsive revision, including a strong example of converting a speculative relationship into a structural test and rejecting it. Their recurring limitation was milestone overpromotion, a familiar eagerness to convert favorable local results into readiness claims before visible defects were resolved. They required operator challenge at important quality boundaries and did not sustain closure through the full benchmark. We are not altogether certain these newer iterations are in fact performing better than the earlier Opus 4.6 for our use cases.

The common pattern across this tranche was local competence without dependable project-wide closure. These models performed many of the individual behaviors seen in the strongest runs. What they did not demonstrate was the same behavior recurring through the full eight-stage investigation.

GPT-5.6 Sol | A New Class of Contender

When GPT-5.6 Sol was introduced, we seized the opportunity to evaluate it against our real-world benchmark. As the name implies, we expected incremental improvement from GPT-5.5 but instead found the model operating in a league of its own, with all three GPT-5.6 Sol runs completing the benchmark at different effort levels.

Sol was far from infallible. Its runs declared checkpoints clean or complete before later review found meaningful problems. The distinctive pattern was what happened next. Sol repeatedly responded to a local failure with a structural fix, reassessing the quality-control process that had let the mistake through and building scaffolding, such as codifying file hashes for even routine operations, to keep entire classes of failure from recurring.

The xhigh run provides the clearest example because its error began with a valid observation. fast16 contains a program of 101 byte-pattern rules that recognize locations inside an executable, capture addresses, replace code, and repair the executable metadata those changes require. Replaying that rule program across a larger software collection, Sol found that some rules fired not only in LS-DYNA, the engineering package fast16 targets, but also in MOHID and PKPM, two applications built from a similar Fortran lineage. It proposed that fast16 might be a general compatibility component rather than a tool engineered for sabotage.

The collisions were real, and we made similar observations early in our own investigation, but the explanation gave too much weight to the mere presence of matches. The model corrected course by demanding greater rigor of itself, asking whether the matches produced a meaningful modification sequence. In LS-DYNA they did. In MOHID and PKPM they produced only haphazard fragments, often triggered by generic compiler-generated code.

What first looked like broad compatibility was better explained as collateral risk from loose rules. Sol not only self-corrected but found better footing for that correction than we did. It then withdrew the compatibility hypothesis, preserved the valid measurements, restored the LS-DYNA modification mechanism as the authoritative account, and marked the rejected branch as historical provenance so later analysis would not inherit it.

5.6 Sol’s performance has pushed the boundary of the possible for automation in cyber threat investigations. Given its ready availability, we are interested in seeing how these capabilities enable the practitioner ecosystem to advance the state of the art in the same manner as alternate research disciplines like math and physics.

Project-Scale Recovery

What separated the completed runs from the rest was not technical insight, error detection, or willingness to revise. Every cohort supplied examples of each. The recurring difference was the scale at which recovery occurred. Across a long-horizon investigation, the completed runs did more than correct the sentence or script in front of them. They rebuilt the part of the project that later work would trust, in a repeatable pattern:

1. Withdraw the contradicted claim rather than softening its wording while continuing to rely on it.
2. Map the blast radius, identifying every conclusion, artifact, and test that depends on the disputed result.
3. Repair the cause, correcting the analysis or the quality-control gap that let the error through.
4. Carry the correction through the files another analyst or later stage will actually use.
5. Reopen the artifacts and run a check capable of disproving the corrected claim.
6. Separate work that blocks the current conclusion from uncertainty that can be disclosed and deferred.

That last step is easy to underestimate. An investigation can fail by stopping too early, and it can also fail by expanding forever. Deciding which unresolved questions block a conclusion is what convergence means in this benchmark.

This is not a single new reasoning faculty. It is the coordination of familiar capabilities over time, spanning correction, scope control, verification, state management, synthesis, and stopping judgment. The evidence supports project-scale recovery as a common feature of the completed runs. It does not prove a permanent intelligence threshold, and looking only at finishers cannot explain why every other trajectory fell short. The number of runs per family is small, and operator involvement was consequential throughout. What survives those caveats is the modest formulation that the completed runs repeatedly re-established a trustworthy investigative state after later evidence destabilized it.

Notes on Cost

Across all experiments, our runs consumed more than 23 billion tokens across model families and effort levels. The aggregate cache read rate was 93.58%, translating to different discounting rates across providers. Our self-hosted GLM-5.2 run offers a floor for comparison, producing 267.41M tokens on a $100 budget and a decent level-1 attempt charitably comparable to some GPT-5.5 and Opus 4.7 performance.

What These Results Mean for Analysts

The practical lesson stops well short of replacement for senior reverse engineers. The strongest runs still made serious semantic errors, accepted weak quality controls, promoted work too early, and depended on operator review at consequential moments. The new capability is that some runs remained useful after those failures. They owned substantial investigative workstreams, recovered from invalidated theories, preserved the valid parts of earlier work, and continued into publication-oriented analysis without starting over.

That changes the role these systems can plausibly play. A weaker model may be valuable as a local copilot, explaining a function, testing a hypothesis, or drafting a section. The strongest observed runs could act more like supervised investigative agents, maintaining and repairing a larger body of work across days, artifacts, and changing evidence. The supervision qualifier remains essential. Humans defined the investigative objective, controlled evidence release, exposed important blind spots, decided what quality meant, and retained final publication authority.

The scale of the shift deserves emphasis. Reverse engineering and malware analysis have been kept from scaling for three decades by the scarcity of expert practitioners. That constraint does not disappear, since expert guidance still determines whether the work can be trusted, but a single expert supervising these systems can now expand their output by any metric we track.

Conclusion

The line the benchmark exposed ran between local competence and sustained ownership of an investigation, rather than between smarter and lesser models. GPT-5.5, GLM-5.2, and the Opus 4.x family frequently produced valuable analysis. GPT-5.6 Sol also made meaningful errors. What distinguished the completed runs was their repeated ability to recover and diffuse that correction throughout the whole project, rather than just confronting their immediate context.

Having completed this stage of our evaluations, we took the best candidate produced by 5.6 Sol High and put it through an extensive adversarial refinement process using an ensemble of models to produce the highest automatable quality of IDBs and investigation artifacts. We are sharing these so other researchers can verify the work output against the sample and build on them rather than start from the raw binary. We make no claim that it is perfect, only that it is the greatest level of automated refinement the most capable models achieved through proper methodology, repeated standard enforcement, and a lot of tokens burned.

That is a less dramatic claim than a new form of autonomous intelligence. It is also more useful. For defenders, the question that matters most is whether the models can reliably preserve and advance a trustworthy investigation. Once we can count on that, it’s up to us to redefine a greater scope of impact for a new frontier of cyber threat investigations.

Resources

fast16-idbs – Gold-Master IDA Databases

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.

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.

1. Provenance and target validation: Can the organization, system, location, and timeframe be independently established?
2. Interface visibility: Can the actor display a login page, dashboard, or management interface?
3. Authenticated interaction: Can the actor navigate the live interface or query current values?
4. Write or control capability: Can the actor change a setting, logic file, operating mode, or command value?
5. Process effect: Did the change alter an operational process outside the interface?
6. 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.

Assessment current as of 21 July 2026.

Executive Summary

• Compaction is a context-management pattern used across agent systems to compress prior context into a denser working state for long-running tasks.
• SentinelLABS evaluated OpenAI’s native Responses API implementation against our automated malware analysis evaluation harness to measure real-world impact on task quality and cost.
• Compaction reduced input tokens by ~86% with no measurable change to the aggregate evaluation score.
• Our analysis found that compaction can significantly reduce the cost and noise of long-running security workflows without sacrificing task quality.

OpenAI introduced native compaction in a March 2026 engineering post describing extensions to the Responses API. However, the underlying idea is not unique to OpenAI. Anthropic, Google, and other agent frameworks such as LangChain all expose or document related approaches under different names.

The core problem these systems address is familiar to anyone who has built an agentic system: context accumulates faster than it stays relevant, and eventually the model is carrying more history than signal. At that point, task quality degrades and costs climb without a corresponding improvement in output.

OpenAI’s solution was to build compaction directly into the runtime so developers would not need to build custom summarization and state-carrying systems themselves. The company noted that compaction is the mechanism Codex relies on for long-running coding tasks, which positions it as load-bearing infrastructure rather than a convenience feature.

At SentinelLABS, we set out to evaluate how well OpenAI’s compaction would work for automated binary analysis, a domain with its own particular demands on agent memory and state management.

Why Malware Analysis Is a Hard Problem for Agents

Our evaluation harness gives a model access to a decompiler and asks it to complete the following:

• Identify important functions and follow code paths
• Interpret strings, APIs, call relationships, and data structures
• Rename functions or variables based on observed behavior
• Propose types or object models and explain what the malware is doing

We compare the model’s output against golden reference analysis and written reports across scoring metrics for correctness and completeness. To achieve a high score, the model needs to maintain a working theory for the slice of the binary it is analyzing, track evidence already collected, and hold open questions alongside provisional conclusions.

Malware analysis is an iterative process with a low-reward signal. A human analyst might inspect one function, learn something, pivot to another function, revise their theory, check a data structure, then return to update their original conclusion. Models do well in our evaluation where execution paths have straightforward continuity. They struggle when connections are unclear or require multiple rounds of investigation.

In observing model performance, we noticed that the agent tended to carry an increasing volume of tokens between tasks. The pattern is familiar to anyone who has run a ReAct-style agent on a non-trivial problem. Each turn adds more context until the model is dragging the full history of the run behind it, most of which stopped being useful several steps ago.

A human analyst working the same problem does not keep every raw observation equally active. They compress state between sessions. They remember that a function is probably the command dispatcher, that a particular object looks like transport state, that a given path was a dead end. They also write findings in a notebook, externalizing what they want to persist so they do not have to hold it all in working memory.

That distinction between working memory and durable memory is where compaction becomes architecturally useful.

How We Applied Compaction

Our system uses compaction to carry forward the working state: the current goal, what has already been tried, what was learned, which hypotheses remain active, what evidence changed the plan, and what questions are still open.

Specific findings and exact artifacts live outside the model context in durable storage. For malware analysis this includes logs and tool outputs, decompiled functions, intermediate artifacts, and ground-truth comparisons. When the agent needs exact evidence, it retrieves it from storage rather than relying on the compacted context to preserve it verbatim. In our use case tool use and response for binary exploration created increasingly large prompts. As the model used more tools to explore the space it added new findings – not all of them necessary. We leveraged compaction to summarize those tool calls and findings into more manageable chunks to maintain the working memory of the agent, but dramatically reduce the operational token overhead.

This split is what makes compaction measurable. A workflow that relies on compaction to preserve exact evidence will eventually produce incorrect answers when summarization or compression flattens crucial details. A workflow where compaction handles working memory and durable storage handles facts can be evaluated cleanly, because the boundary between the two is explicit.

Results

Across several long-running malware analysis agent evaluations we, compared runs with compaction enabled against runs without it.

The token reductions were substantial. The aggregate evaluation score holding flat is what matters. We were able to carry forward enough state for the workflow to continue correctly while dramatically reducing the context processed per run.

One metric did decrease: domain object modeling, meaning the model’s ability to recover the higher-level objects and structures that explain the malware’s behavior. This is not a minor caveat. For malware analysis, object and type recovery is often where the most analytically valuable conclusions are drawn.

Our read is that compaction occasionally flattened structural reasoning that would have been useful later, and it reinforces why exact artifacts must live in durable storage rather than the compacted context.

Nevertheless, our research found that compaction made longer-running analysis practical and preserved the main evaluation outcome while doing it.

Implementation

Model providers expose compaction capabilities differently. For example, Anthropic and OpenAI both provide server-side compaction; however, OpenAI exposes an additional standalone compaction endpoint. This allows developers to solve the same problem at different points in their workflows as explained below.

Server-side Compaction

This is the simpler starting point. The Responses API call includes a compaction threshold in context_management. When context length crosses that threshold, the API compacts prior context automatically during the response, with no separate call required from the application.

Standalone Compaction

This gives explicit control over when compaction happens. The application sends a context window to /responses/compact and receives a compacted context window back, which then becomes the input for the next response call.

For our malware analysis workflows, standalone compaction was useful at phase boundaries. For example, compacting after initial triage before entering deeper function analysis. This also lets you inspect metrics before and after compaction, which is useful for identifying where specific evidence is being compressed and whether that compression affects downstream scoring.

The important constraint with the standalone endpoint is to treat the returned compacted window as the next canonical context window. Do not prune it manually unless the workflow has a specific and well-understood reason to do so.

A practical decision rule for choosing between them:

How to Use Compaction

The main takeaway for us was that compaction works best when it is part of a broader context-engineering strategy.

1. Separate working memory from source-of-truth artifacts. Compaction is appropriate for the immediate state the model needs to continue working. Exact evidence belongs somewhere else. This boundary matters both for correctness and for being able to evaluate whether the compacted run behaved correctly.
2. Compact long-running workflows. Compaction has the most impact when a task involves many steps and repeated tool use. Short interactions have little to compress.
3. Start with server-side compaction. For most agent loops it is the fastest way to learn whether compaction helps. Move to standalone when compaction policy becomes part of the task or evaluation design.
4. Do not evaluate on cost alone. A run can become significantly cheaper while losing task quality, depending on what was compacted. Resource and outcome metrics need to be tracked together.
5. Preserve negative information. Long-running agents need to remember what failed, not just what worked. Failed paths carry state that informs subsequent decisions, and compaction can discard them if the workflow does not explicitly mark them as worth preserving.
6. Treat compaction as lossy until proven otherwise. Use evaluations, traces, and artifact comparisons to verify that the compacted run still behaves correctly. Our domain object modeling result is a reminder that what looks like clean compression can still affect specific downstream capabilities.

Conclusion

Compaction is part of a broader shift from prompt engineering to context engineering. Prompt engineering concerns what we ask of the model in a single turn whereas context engineering concerns what the model gets to see across multiple turns: what gets compressed, what gets retrieved, what gets written to durable state, and what gets discarded.

For agents running long-horizon tasks, context engineering may be as important as model selection. A strong model with poor state management will lose the thread on a complex task. A model with better context discipline may make steadier progress and complete more tasks. That tradeoff compounds quickly across the kind of multi-step security workflows we are trying to evaluate.

Without compaction, realistic long-running security agent workflows become too large, noisy, and expensive to measure cleanly. With it, the scope of what is practical to evaluate expands. We view compaction not just as a tool for making agents cheaper, but as part of the infrastructure required to evaluate whether they actually work.

References

• OpenAI: Responses API + Codex https://openai.com/index/equip-responses-api-computer-environment
• Anthropic: Long-Running Agent Harnesses https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• LangChain: Deep Agents + Context Compression https://docs.langchain.com/oss/python/deepagents/context-engineering
• Jason Liu: Compaction As Something To Evaluate https://jxnl.co/writing/2025/08/30/context-engineering-compaction
• Context Compression For Long-Horizon Agents https://arxiv.org/abs/2601.07190

Executive Summary

• SentinelLABS has analyzed a Rust macOS implant that embeds a 3.5 KB prompt-injection payload of 38 fabricated “system” messages, built to steer an LLM-assisted triage pipeline into aborting or refusing its analysis.
• Command-and-control runs over a Telegram Bot API polling loop, with AES-GCM payloads over certificate-pinned TLS.
• The implant self-redacts its Telegram bot token in its own runtime output, denying it to anyone who captures logs or crash artifacts.
• We assess with high confidence that the implant, which we track as macOS.Gaslight, belongs to a cluster of DPRK-aligned macOS activity.

Introduction

In early June, an Apple XProtect update surfaced a Mach-O sample that had been uploaded to VirusTotal on May 22. The XProtect rule targets the file purely on its hash rather than on any internal strings or bytecode, yet the sample remains undetected by static engines on VirusTotal at the time of writing. The binary is ad hoc signed and carries the identifier endpoint-macos-aarch64-5555494492fc075f441637fb9d894913dde3a2ea.

The sample is a macOS implant and infostealer written in Rust. Its most notable feature is an embedded cascade of fabricated system-failure messages, designed to make an LLM-assisted triage agent doubt its own session. It attacks the agent’s perception, rather than the sandbox it runs in. Accordingly, we dub this family macOS.Gaslight.

We assess with high confidence that this implant sits within a cluster of DPRK-aligned macOS activity. Apple’s XProtect detects the sample under the rule MACOS_BONZAI_COBUCH, and SentinelLABS associates the BONZAI signature family with North Korean threat activity. A sibling BONZAI sample is additionally caught by Apple’s AIRPIPE rule, a family SentinelLABS likewise ties to North Korean activity.

Command & Control | Telegram Bot API

The implant’s command-and-control channel is a Telegram Bot API getUpdates polling loop. The polling branch executes only when no webhook is registered, and the dispatch handler keys on three Telegram error codes: BotBlocked, InvalidToken, and Conflict.

Telegram issues a Conflict response when two instances of the same bot token poll simultaneously, so the implant treats that response as an implicit single-instance lock. A second copy detects the conflict and terminates.

Once the bot token validates and the polling loop is active, the operator can task the implant, including through the interactive shell described below, and collected data is returned over the same channel using Telegram’s multipart attach:// file-upload mechanism.

The bot token, the chat ID (tg_room_id), and the rest of the operator configuration are supplied at runtime and are absent from this sample. Accordingly, the analysis below is based on static examination of the binary and its embedded payloads.

Transport Hardening | AES-GCM Over Pinned TLS

All C2 payloads are encrypted with AES-GCM, implemented using the pure-Rust aes-gcm 0.10.3 crate, with a fresh nonce generated per message via CCRandomGenerateBytes. The AES key is supplied at runtime through the aes_key field in the operator config rather than being embedded in the sample.

On top of the payload encryption, the implant configures a custom certificate trust anchor and calls SecTrustSetAnchorCertificatesOnly, restricting TLS trust evaluation to that anchor alone. This certificate pinning rejects connections intercepted by a standard proxy CA, frustrating network-level inspection of the operator’s traffic.

The implant also honors the host’s proxy settings, reading the active system proxy configuration via SCDynamicStoreCopyProxies and routing the traffic from its Rust reqwest/hyper networking stack accordingly. As a result, the C2 can still reach the operator on networks that force outbound connections through a proxy.

Taken together, those choices make the channel harder to inspect in transit while still allowing it to operate in tightly managed enterprise networks.

Operator Access | An Interactive Shell

After validation and activation, the operator gains an interactive shell. Two co-located command menus define six verbs.

There is some evidence of a seventh command, focus, but we were unable to recover further details from our analysis.

The implant creates an IOPMAssertionCreateWithName power-management assertion to prevent system sleep. Blocking sleep sustains long-running C2 polling and collection across periods of user inactivity, making the implant resilient to a host that would otherwise idle.

All told, the functionality provides the operator with a persistent, interactive foothold on the host.

The 15-Field Cross-Platform Operator Config

The implant reads its operator configuration using serde, a widely used Rust serialization and deserialization framework.

The operator provides the implant with a config blob at runtime and serde fills in a predefined set of fields. By default, serde matches incoming config keys to fields by their literal names, so the entire configuration schema of 15 field names is baked into the binary as plaintext.

The Linux- and GitHub-related fields are not exercised in the sample, suggesting the schema is an operator-facing interface to a broader toolset.

Collection | A Gated Python Stealer With Its Own Runtime Supply Chain

The implant carries a 6.6 KB base64-encoded Python script which serves as a data collection module. Once decoded, it harvests:

• Chrome, Brave, Firefox, and Safari browser data
• Terminal command histories
• Installed application listings
• A running-process snapshot via ps aux
• System hardware and software profile via system_profiler
• A raw copy of login.keychain-db

Collected artifacts are archived to temp/collected_data.zip and uploaded to the operator via Telegram.

SentinelLABS has previously documented Atomic macOS Stealer (AMOS) harvesting the same login keychain copy and browser data and an early Rust macOS stealer targeting login.keychain-db in 2023.

A separate 2 KB base64-encoded bash installer fetches and stages a self-contained cpython-3.10.18 interpreter from the astral-sh/python-build-standalone project. The installer, a prerequisite for deploying the Python stealer, carries the literal constants PY_VERSION=3.10.18 and BUILD_DATE=20250708 and targets both arm64 and x86_64 macOS. The widespread use of emojis and strict adherence to comment headers are consistent with LLM-generated output.

Microsoft has previously described macOS stealers bundling Python via PyInstaller and Nuitka. However, fetching a standalone CPython build from astral-sh/python-build-standalone at runtime has not been previously documented as far as we are aware. The separation keeps the main implant in Rust while letting the operator stage a fuller Python-based collection environment only when needed.

We identified init_python_enable in the serde schema as the configuration field associated with both the stealer and installer. Consistent with our earlier observations, we found no exact runtime branch logic, so we describe both only as configurable capabilities present in the binary.

Persistence | An Apple System-Service Masquerade

Persistence is achieved through a LaunchAgent. This implant’s plist carries the Label value com.apple.system.services.activity. Masquerading within Apple’s com.apple.* namespace is a tactic widely used in many macOS malware families, including those previously tied to DPRK-linked activities.

In order to write a valid absolute path to itself into the plist’s ProgramArguments array, the implant resolves its own executable location at runtime via __NSGetExecutablePath.

The implant’s persistence behavior is controlled through the persist_enable serde config field, and again we did not recover a separate static branch that would confirm exactly how installation is triggered in this sample.

OPSEC | Bot-Token Self-Redaction

Telegram bot tokens are a known weak point in bot-based C2. If the token can be recovered, defenders can use it as a detection artifact and even query the Telegram Bot API directly, exposing the bot’s chat history, operator commands, and registered webhooks. macOS.Gaslight addresses this with a self-redaction routine built into its Telegram URL constructor.

When the URL path segment is the 4-byte literal “file” (0x656c6966 little-endian), the constructor substitutes the token that follows with the hardcoded placeholder file/token:redacted, preventing the live bot credential from appearing in any diagnostic output or error string the implant produces at runtime.

The logic prevents anyone who captures the process’s logs, errors, or crash artifacts from determining the bot token, which otherwise is only available in the config itself and cannot be recovered from the sample.

NVISO Labs has previously noted that most documented Telegram bot abuse embeds recoverable tokens; macOS.Gaslight’s runtime self-redaction appears novel relative to that reporting.

A Prompt Injection That Targets the Analyst

The implant does little conventional anti-analysis. It resolves its API calls at runtime through dlsym so as to avoid embedding them in the static symbol table, and it locates its own executable dynamically rather than from a hardcoded path.

What makes the sample notable is its attempt to mislead the analyst reading the output. It carries a 3.5 KB Markdown-fenced blob of hostile data containing 38 fabricated “system” messages delimited with {{DATA}} tokens.

The {{DATA}} tokens and the surrounding Markdown fence mimic an LLM triage harness’s own prompt scaffold, blurring the boundary between untrusted sample data and trusted instructions.

The scaffold contains fake system messages about token expiry, out-of-memory kills, disk exhaustion, and repeated operation failures. It also plants bogus warnings about injection vulnerabilities and static-analysis flags. The aim is to push an LLM agent into aborting, truncating, or refusing analysis.

Check Point first documented this kind of analyst-targeting prompt injection publicly in 2025, describing a Windows proof-of-concept that used a single direct-instruction prompt injection to evade AI-based detection.

Socket has since documented a Hades supply-chain payload whose stealer opens with a fake prompt-injection header to pollute AI-assisted analysis, while the leaked Shai-Hulud code carried an “Anthropic Magic String” intended to stop Claude Code from analyzing it. Each relied on a single injected block or header rather than the 38-message harness-spoofing cascade seen here.

Previous SentinelLABS research, by contrast, examined malware that uses LLMs to generate or support capability at runtime rather than interfere with analyst tooling.

Conclusion

macOS.Gaslight packs considerable capability into a single, persistent Rust binary, bundling a credential and session-data stealer, an interactive shell, and a self-staged Python collection chain behind a hardened Telegram C2. Aside from the runtime-fetched standalone CPython interpreter, these are all established macOS tradecraft.

However, macOS.Gaslight is noteworthy for its analyst-targeting prompt injection, an attempt to weaponize the LLM-assisted triage pipelines that increasingly sit in the reverse-engineering loop.

Anyone building such tooling should treat the contents of the samples they triage as adversarial input, never as instructions, and be prepared to keep hostile content out of the model entirely. As LLM-assisted analysis becomes routine, defenders should expect more samples built to exploit it.

Indicators of Compromise

In this final video in our LABScon Replay series from LABScon 25, we present the keynote from SentinelLABS’ own Juan Andrés Guerrero-Saade (JAGS), VP, Intelligence & Security Research and Senior Technical Fellow.

In this engaging talk, Juan argues that cybersecurity is reaching the end of its experimental era. Years of piling complexity onto non-standardized software stacks have produced systems that are difficult to steer and costly to manage through human attention alone.

A key theme in the talk is JAGS’ argument that large language models change that equation. He describes them as a new source of cheap, effectively unlimited evaluative power and as a “lossy compression of human knowledge”. Used well, that kind of mechanized intelligence can give defenders a scalable way to assess, prioritize, and act without leaning so heavily on scarce human expertise. In practical terms, it lowers the cost of analysis and changes how defensive work can be done at scale.

That argument also shapes JAGS’ broader point about how security should evolve once this capability is built in rather than bolted on. Drawing on ideas from cybernetics, JAGS urges the industry to move beyond purely adversarial ‘agonistic’ design and toward systems in which human expertise and artificial evaluative power work together to produce better outcomes.

Rather than defending old product categories or familiar workflows, the talk points toward a more standardized, more automated, and more sustainable future for the industry. For anyone interested in how AI may reshape the practice, cost, and structure of cybersecurity itself, this keynote is essential viewing.



About the Author

Juan Andrés Guerrero-Saade (JAGS) is VP for Intelligence and Security Research and Senior Technical Fellow for AI Innovation, overseeing intelligence production and AI applications towards security problems. He’s also Distinguished Resident Fellow for Threat Intelligence at the Johns Hopkins SAIS Alperovitch Institute. His research work is the subject of two permanent exhibits at the International Spy Museum in Washington, DC. He’s a member of OpenAI’s Frontier Risk Council, founded the premier threat intelligence conference LABScon, and is a co-host of the Three Buddy Problem podcast.

LABScon 2026 | Call For Papers

Submission Deadline: June 19, 2026

LABScon is a unique venue for original research to be shared among peers. The benefit of an invite-only audience of researchers is that there’s no need for long preambles or introductions – speakers are encouraged to dive right into their technical findings.

• Original content only.
• Talks are 20 minutes long + 5 minutes for Q&A.
• Workshops are 90 minutes long.
• LABScon is primarily a threat intelligence and vulnerability research conference but we keep an open-mind.

About LABScon

This presentation was featured live at LABScon 2025, an immersive 3-day conference bringing together the world’s top cybersecurity minds, hosted by SentinelOne’s research arm, SentinelLABS.

Keep up with all the latest on LABScon here.

In this LABScon 25 presentation, ESET researchers Matthieu Faou and Zoltán Rusnák present the first technical evidence that Gamaredon actively facilitated Turla’s access to high-value Ukrainian targets in Ukraine.

Across incidents observed between February and June 2025, Gamaredon tooling, including PteroGraphin and PteroOdd, was used to deploy Turla’s Kazuar backdoor and, in at least one case, restore Turla’s access after the group appeared to have lost its foothold.

The talk opens with a current view of Gamaredon’s tradecraft. Still one of the most active espionage actors targeting Ukraine, the group relies on relentless spearphishing, lightweight custom tooling, and fast operational tempo to compromise military and government organizations. Matthieu and Zoltán show how those patterns continue to evolve while remaining highly effective in a wartime environment.

The researchers’ provide evidence of direct operational collaboration between Gamaredon and Turla, detailing concrete cases in which Gamaredon activity enabled Turla operations on already compromised systems. The talk offers a rare look at how Russian cyberespionage operations may divide labor in practice, with one actor establishing or maintaining access and another deploying a more advanced espionage platform to exploit it.

The talk also examines Kazuar v2 and v3, Turla’s flagship backdoor, and unpacks what those versions reveal about the group’s operational priorities. From deployment chains to capability depth, the analysis helps defenders connect initial access activity with downstream post-compromise objectives and better understand how sophisticated implants are sustained inside contested networks.

This talk is essential viewing for defenders, threat hunters, and intelligence teams tracking Russian state-aligned activity in Ukraine, particularly those interested in access brokering, inter-group collaboration, and the continuing evolution of Turla’s malware stack.



About the Authors

Matthieu Faou is a senior malware researcher at ESET where he specializes in researching targeted attacks. His main duties include threat hunting and reverse engineering of APTs. He has spoken at multiple conferences including Black Hat USA, BlueHat, Botconf, CYBERWARCON, NorthSec, and Virus Bulletin.

Zoltán Rusnák is a senior malware researcher at ESET, with a decade of experience in malware analysis and research. He has worked extensively on identifying and systematically monitoring major botnet families, including the infamous Emotet and Trickbot. His background in large-scale botnet tracking has been central to his current research on Gamaredon.

LABScon 2026 | Call For Papers

Submission Deadline: June 19, 2026

LABScon is a unique venue for original research to be shared among peers. The benefit of an invite-only audience of researchers is that there’s no need for long preambles or introductions – speakers are encouraged to dive right into their technical findings.

• Original content only.
• Talks are 20 minutes long + 5 minutes for Q&A.
• Workshops are 90 minutes long.
• LABScon is primarily a threat intelligence and vulnerability research conference but we keep an open-mind.

About LABScon

This presentation was featured live at LABScon 2025, an immersive 3-day conference bringing together the world’s top cybersecurity minds, hosted by SentinelOne’s research arm, SentinelLABS.

Keep up with all the latest on LABScon here.

When a company suffers a cyber breach, its stock price often takes a hit, but the timing, depth, and duration of that reaction are far less predictable. In this LABScon25 presentation, Mick Baccio and Scott Roberts explore whether public indicators of breach activity can be used to anticipate market response before formal disclosure.

Drawing on sources such as EDGAR filings, executive blog posts, and social media chatter, the speakers examine how public breadcrumbs can reveal incident activity early enough to support an opportunistic trading strategy. At the center of the talk is their “15/30” hypothesis: short the stock after a breach becomes visible, then flip long as the market recovers.

To test the idea, Baccio and Roberts used AI-assisted data collection to build a dataset of public disclosures relating to “material” cyber breaches at U.S. companies. They then compared their initial, intuition-led model with a more structured time-series analysis based on a Hidden Markov Model to see whether a more rigorous timeline could improve performance.

Along the way, the presentation digs into real-world breach cases, market misreads, and missed opportunities. One particularly useful comparison looks at two similarly sized casino operators hit by ransomware around the same period, illustrating how market outcomes can diverge sharply depending on factors such as response strategy, disclosure dynamics, and investor perception.

After working through a set of highly mixed results, the speakers arrive at what they call “quantitized nihilism”, a conclusion that questions many of the assumptions analysts bring to cyber-event trading and how the market actually values cyber failures.

This talk is essential viewing for security practitioners, investors, and analysts interested in the messy intersection of cyber risk, public disclosure, and market psychology.



About the Authors

Mick Baccio is a globally recognized security strategist with a career spanning offensive operations, threat intelligence, and national-level incident response. He currently advises organizations around the world through his role at Splunk, helping security leaders improve operations through data-informed approaches. Mick was the first Chief Information Security Officer for a U.S. presidential campaign (2020), and previously served in the Obama White House as the Chief of the Threat Intelligence Branch.

Scott J. Roberts is a cybersecurity leader with over 15 years of experience specializing in cyber threat intelligence and threat hunting after leadership roles at GitHub, Apple, and Splunk. He blends machine learning with traditional intelligence frameworks to track and disrupt nation state and criminal adversaries.

LABScon 2026 | Call For Papers

Submission Deadline: June 19, 2026

LABScon is a unique venue for original research to be shared among peers. The benefit of an invite-only audience of researchers is that there’s no need for long preambles or introductions – speakers are encouraged to dive right into their technical findings.

• Original content only.
• Talks are 20 minutes long + 5 minutes for Q&A.
• Workshops are 90 minutes long.
• LABScon is primarily a threat intelligence and vulnerability research conference but we keep an open-mind.

About LABScon

This presentation was featured live at LABScon 2025, an immersive 3-day conference bringing together the world’s top cybersecurity minds, hosted by SentinelOne’s research arm, SentinelLABS.

Keep up with all the latest on LABScon here.

Executive Summary

• Following disclosure of the TraderTraitor attack against LayerZero Labs in April 2026, SentinelOne identified an additional victim with the same macOS backdoors.
• Our analysis explores the mechanics of these backdoors and the expanded targeting against a victim in the IT services sector with no relationship to cryptocurrency trading.
• We also identified more weaponized GitHub repositories from the social engineering schemes used to target job seekers in these campaigns.
• This report expands on how Terraform lock files enable the delivery of malware from custom Terraform provider registries controlled by the attackers.

Overview

Throughout 2026, the financially motivated DPRK state-sponsored Lazarus subgroup TraderTraitor (aka UNC4899, PUKCHONG, Jade Sleet) has engaged in campaigns targeting entities involved in cryptocurrency trading, including a high-profile attack disclosed in April where USD 292 million was stolen from KelpDAO through a compromise of LayerZero.

KelpDAO is a decentralized finance (DeFi) protocol that supports restaking Ethereum; LayerZero Labs provides services with the capability to exchange cryptocurrency across different blockchain platforms.

TraderTraitor compromised LayerZero Labs and determined methods to create a fake cryptocurrency minting event, which the attacker combined with a DDoS against validation servers so that compromised servers would approve an illegitimate mint event, leading to the massive theft.

Following the public disclosure of this breach, SentinelOne identified an additional victim infected with the macOS backdoors, FLATROOF (aka macOS.Gaslight) and ROOFDECK, which were first observed in the LayerZero Labs attack.

Unlike the previous high-profile victim, this target was a much smaller organization in the IT services industry. Our investigation revealed insights into what happens when this threat actor compromises a smaller organization that we believe ultimately yielded insufficient value to sustain the intrusion.

Weaponized Terraform Coding Projects

Each campaign related to this wave of activity uses social engineering via fake job interview lures, a traditional Contagious Interview approach common among DPRK actors. The attacker makes contact with job seekers from the company that is ultimately compromised; the GitHub profile of each targeted job seeker we identified falls into DevOps or cryptocurrency/FinTech engineering projects.

The GitHub repository themes for coding project lures are designed as infrastructure engineering projects related to the company that the DPRK actors are posing as. By pivoting from the gtn-candidate-repo repository shared by LayerZero Labs in their incident report, we identified additional lures, which included references to the companies Northwind and Novacart.

It is unclear if these were fabricated companies used by the threat actor, or if they were posing as hiring teams from real companies with these names; one Northwind example describes it as an ecommerce company launching in the near future. Other repository names that we identified include:

• Northwind-IAC
• novacart-interview
• terraform-candidate-repo

The repositories contain a weaponized .terraform.lock.hcl file in the coding project with a custom provider that points to a domain controlled by the attacker. We identified three malicious provider domains across multiple repositories:

registry.hashicorp-aws[.]com
registry.hashicorp-aws[.]io
registry.hashicorp-terraform[.]io

When the victim runs terraform init with the weaponized lockfile in place, Terraform treats the custom provider as the source of truth, resulting in Terraform downloading and executing the malicious provider modules.

Developer awareness can lead to friction against this type of attack: in one repository, the candidate being interviewed added a note saying that they removed a typosquatted provider from the project’s original lock file, which may suggest they thought the interviewer was testing for their security awareness.

According to the LayerZero Labs report, the attackers installed the FLATROOF and ROOFDECK macOS backdoors after an employee installed a weaponized interview coding project on their company workstation. TraderTraitor used the backdoors to collect API keys from the organization and to escalate privileges to expand into the victim’s Amazon Web Services and Google Cloud Platform environments.

While we lack insight into many of the subsequent infections resulting from the GitHub repositories we located, SentinelOne identified an unrelated victim by hunting through our telemetry for the macOS backdoors observed in the LayerZero Labs attack.

Additional Victim

The Victim

The affected organization is an IT services provider based in India and unaffiliated with cryptocurrency. One endpoint was involved: an Apple Silicon MacBook belonging to a DevOps engineer. The engineer ran Terraform and Ansible against AWS, OVH and OpenStack on most working days, and the machine held cloud credentials and source control access: much like LayerZero Labs’ “Developer1”. Individuals whose social media profile advertises infrastructure or DevOps work are candidates for this type of attack, and the value of the target is whatever their laptop can reach.

Infection Timeline

According to our telemetry on this host, both backdoors were on disk as far back as March 18, so we cannot prove how they were delivered. They remained dormant until March 29, when beaconing and host activity began.

The implants were first launched by Cursor on March 29, seconds after the cloudshield workspace was opened.

macOS Malware

We observed two malware families being deployed in the compromise, identical to the ones described in the LayerZero Labs attack, named FLATROOF and ROOFDECK (by LayerZero Labs and Mandiant). Both are ARM64 backdoors for macOS written in Rust.

FLATROOF

We observed the FLATROOF backdoor deployed under the name SystemUpdate to ~/Library/com.apple.iTunesCloud/SystemUpdate. It is likely intended for initial data collection from the victim machine and to deploy secondary payloads.

Immediately after starting, FLATROOF suppresses Gatekeeper by removing the com.apple.quarantine attribute from ROOFDECK and sets the executable bit on it; the second implant runs with no signature check and no user prompt.

xattr -rd com.apple.quarantine .../com.apple.internal.ck/iSync
chmod +x .../com.apple.internal.ck/iSync

A detailed analysis of FLATROOF (aka macOS.Gaslight) was published by SentinelLABS in June 2026. Here, we present a short summary of the backdoor’s capabilities as denoted by its supported C2 commands:

The backdoor also carries a data-harvesting Python module, used to gather the following data and exfiltrate them over Telegram using a built-in Telegram bot token:

• Chrome, Brave, Firefox, and Safari browser data
• Terminal command histories
• Installed application listings
• A running-process snapshot via ps aux
• System hardware and software profile via system_profiler
• A raw copy of login.keychain-db

ROOFDECK

ROOFDECK acts as a more sophisticated backdoor with broader reconnaissance and lateral movement capabilities. We observed it dropped under the name iSync to ~/Library/com.apple.internal.ck/iSync.

It is clear from the design of the implant that it is intended to be used as an additional deployment after initial foothold and control are established, since it needs a pre-existing configuration file containing at minimum a Nostr public key of an attacker-controlled profile to allow it to connect to its C2 server for the first time.

ROOFDECK uses a local configuration file ~/.config/.repl_history to store C2 URLs and keys and to set beaconing behavior.

Upon first execution, it pulls live Nostr relays from api.nostr[.]watch/v1/online and combines them with a hardcoded relay list belonging to legitimate Nostr services, then searches the relays for an operator’s profile on the Nostr network based on a public profile key given in the configuration file nostr_public_keys. When found, it reads the website field of the profile and uses that as its C2 URL. TraderTraitor has previously used Nostr.

The following is a list of Nostr relays used for operator profile discovery:

wss://relay.damus[.]io
wss://nos[.]lol
wss://nostr[.]mom
wss://relay.snort[.]social
wss://offchain[.]pub
wss://relay.nostr[.]band
wss://nostr.oxtr[.]dev
wss://nostr[.]wine

Persistence was achieved via a plist entry ~/Library/LaunchAgents/loginwindow.plist, with a dynamically specified application identifier string. It uses a hardcoded --type=renderer parameter to make the implant process appear legitimate.

ROOFDECK supports a wide variety of C2 commands for managing the implant, performing reconnaissance, exfiltrating data and executing attacker code. The C2 endpoint is hardcoded as /app_version. Polling for commands is done via HTTPS with a custom pinned TLS certificate embedded in the implant, shown below.

Interestingly, the malware author used default metadata settings with mkcert, which exposed that they are running on a Linux QEMU-based VM using the username ub. We identified multiple domains using a certificate containing this certificate CN (listed in the Indicators of Compromise section).

Subject = Issuer (self-signed):
    O  = mkcert development CA
    OU = ub@ub-Standard-PC-Q35-ICH9-2009
    CN = mkcert ub@ub-Standard-PC-Q35-ICH9-2009
Serial:    1CD6D13FF15ADBF7A42025D10EC99B4A
Key:       RSA 3072-bit
Validity:  2025-06-20 11:06:53 UTC -> 2035-06-20 11:06:53 UTC  (10-year mkcert default)

ROOFDECK commands are signed with the operator’s private key and their integrity is verified using an embedded public key before execution. The command functionalities are separated into distinct handlers in the source code. The implant re-implements many common shell commands related to directory and file operations, another tactic often used in more sophisticated North Korea-aligned toolsets, including Lazarus’ LightlessCan.

Session & Control

Execution

File system / data

Transfer

Reconnaissance / surveillance

All C2 commands are signed on the server side by an attacker-controlled private key. The public key is embedded in the ROOFDECK payload and is used to verify the origin and integrity of the issued commands before executing them.

-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAzan/EObUVxXNfPHdkDyCVR0AC9apleciK9ZQw+neWo6q+wvAhnLp
Pe7FZLomuwntUgI3afLDblgw9t19Kh7w/8CVwFncxh4PdqtdYno4teQ6fDLKXSWa
ZBG7zZ9R22jxPpiY70XKilXJuds34q7pfzVfbLvLTmTWyTtcyrOnRSCOwEHP/gHX
0gX+8sdX7go6O37WwzB4zNvThS+E7hG+fVfrgEaH7IUi3RY9esuBS50UomfYefO3
dK1aDMDWIwVj1skacPR9LazEc6PSGjSXxzI/N2xcpP9QKXn/Pk6r9fBzudhBL3Mw
vWyNi03JbZGtGFiy6Wai6heJqgY7pF1PAQIDAQAB
-----END RSA PUBLIC KEY-----

Another version of ROOFDECK

On April 20, one day after LayerZero Labs’ first public announcement of the KelpDAO incident, the attackers deployed a new version of ROOFDECK to the compromised machine (SHA-1: 5728b11d30586bbfc1d8bd12df1c722a06e767a2, path ~/Library/com.apple.appleaccountd/loginwindow) as an executable named loginwindow. 

After the new version initialized and started beaconing, the attackers used it to remove the old ROOFDECK and FLATROOF binaries. This new ROOFDECK was functionally identical to the previous one, but with stripped symbols and debug information, likely intended to more effectively evade detection. We can only speculate whether this was a reaction to LayerZero Labs’ publication, but the timing is nevertheless interesting.

After the update, we observed intermittent beaconing activity to a new C2 server, grenight[.]com, until June 1. On June 17, the loginwindow binary was moved to Trash.

Conclusion

DPRK-aligned actors like TraderTraitor are leaning heavily into targeting developers to establish a foothold in a network, increasingly through fake job interviews. The incident we investigated shows that not every organization they infiltrate will become a viable target for a massive cryptocurrency theft.

These groups’ initial access efforts include targeting third parties and their software supply chain, which is where much of the industry’s exposure has moved, putting the developer endpoint at the center of the defense. Endpoints used for development carry access to cloud, pipelines and source code, which makes monitoring and protection a high priority for organizations. These campaigns use purpose-built development environments aimed at one engineer at a time, paired with backdoored Terraform builds that differ for each victim.

Recommendations

For organizations:

• We recommend flagging engineers with cloud engineering permissions and source control access as a sensitive group for endpoint security monitoring.
• Look for unsigned binaries executing from the home directory, integrated development environment (IDE) child processes that are not signed IDE components, and outbound TLS from either.
• Reports of interview take-home assignments and unsolicited repositories from these users are worth following up as well, since telemetry alone will not show that a recruiter sent one.
• Consider company policy that prevents using corporate workstations for external job interviews and consider how to enforce this type of policy.
• Educating developers with sensitive access is crucial: the weaponized Terraform provider domain was removed by one job seeker who flagged the typosquatted domain as suspicious. Organizations should add content to their security awareness training programs to highlight the risks of using projects with unknown origins as well as the nature of employees being targeted by threat actors to compromise the organization.

For developers:

• Before running a coding project containing a .terraform.lock.hcl file, ensure that the provider registry belongs to known good domains: anything that is not a known namespace following registry.terraform.io, the official provider domain, should be treated as suspect.
• Malicious packages can also be hosted on the official provider registry domain, so it is important to investigate the source of all packages when using an included lockfile. Terraform’s official registry supports browsing modules and providers, and modules contain a link to its source code.

This report is being published alongside a presentation at LABScon 2026, Don’t Call Us, We’ll Call Your APIs: Anatomy of an Expanding DPRK Multi-Cloud Intrusion. SentinelOne thanks Google and Mandiant for their partnership in providing technical details on this threat actor’s tools and techniques, and Nick Simonian for collaborating on this research.

Indicators of Compromise

IoCs (additional victim)

Custom certificate used for TLS communication

Host IoCs – ROOFDECK

Network IoCs – ROOFDECK

Certificate Domains related to “ub” user

Coding Challenge Repositories

hashicorp-aws[.]com Provider:

hashicorp-aws[.]io Provider:

hashicorp-terraform[.]io Provider:

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 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.

A1: MARKER
A2: =1+2
A3: =CONCATENATE("JOIN","T")
A4: =WEBSERVICE("https://httpbin.org/base64/UkVNT1RPSFgo")
A5: =WEBSERVICE("file:///etc/hostname")
A6: =WEBSERVICE("http://169.254.169.254/metadata/instance?api-version=2021-02-01")
A7: =WEBSERVICE("http://file-service-namespaced:8001/openapi.json")

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.

• OpenAI Hugging Face Incident Technical Report — Published internal chronology; see pages 6–7 and 32–33
• OpenAI Hugging Face Incident and Misalignment — OpenAI’s public account
• Hugging Face July Agent Intrusion Technical Timeline — Separate July incident referenced for comparison only
• OpenAI Black Hat presentation recording — Shows the Artifactory write and message-board examples
• 0Time puthack82d5 relay commit — May 13 initial relay behavior
• 0Time puthack82d5 POST and Git LFS revision — May 13 later relay revision
• Nyx9 — May 26 20:04:11
• Nyx9 netproxy17 relay commit — May 26 20:49:55
• 0Time latnetnew relay commit — Public revision after the 21:08 second-account event
• Nyx9 formbin.xlsx commit — Workbook with local, metadata, and internal-service targets
• 0Time altreg principal code commit — Registration program and Flask wrapper
• 0Time altreg OAuth-debug revision — Final May 30 diagnostic change
• 0x5uo2hen codex_register source commit — Earliest exact public source located
• Microsoft WEBSERVICE function documentation
• Microsoft Azure Instance Metadata Service — Header and access requirements
• openpyxl formula documentation — Formula storage and evaluation limitations

Executive Summary

• Four incidents involving OpenAI, Anthropic, Meta and the UK AI Security Institute (AISI) describe AI agents reaching systems belonging to other organizations without their consent.
• While the causes differ, the consistent factor is the models’ persistence rather than their sophistication, whether as endurance across days of failed attempts or as pivots to entirely new vectors.
• Security teams have traditionally studied the artifacts attackers leave behind, but an agent that simply writes unique, disposable tools makes the model itself the thing worth studying.
• SentinelLABS has been benchmarking frontier models in agent harnesses for months. We observe that the capability that lets GPT-5.6 Sol complete a long-horizon malware investigation is the same one that lets it sustain a two-and-a-half-day intrusion.
• A model may independently determine the methods or targets it uses, but it does not choose its high-level objective or the access it is given to pursue it. We argue that “the AI did it” will not survive contact with the first incident outside a frontier lab.

Four Disclosures, One Pattern

Across four weeks in July and August 2026, OpenAI, Anthropic and Meta have each admitted that their models reached systems belonging to other organizations without consent, and the UK’s AI Security Institute (AISI) published a fourth account describing agents that invented identities and tried to slip a malicious contribution into a live open source project.

The disclosures differ in almost every particular, including whose mistake it was, whether the model defeated a control or simply found one missing, and whether anything was really “escaped” at all. Arguments over those details may run for a while, but the four accounts share something more interesting than their differences, which is that no individual piece of tooling mattered very much.

That observation should sit slightly uncomfortably because most of how intrusions get investigated assumes the opposite.

Early evaluations of LLM cyber capability asked fairly narrow questions. Would a model comply with an obviously malicious request? Did it meaningfully advantage a human attacker? By 2024, the answer was a qualified “yes”. Models could produce serviceable components of an offensive operation, but they could not reliably integrate them into a sustained or adaptive campaign. Beyond short well-defined tasks they became unreliable in ways that made them a liability. The operator was still the operator. The model did scoped work inside a structure someone else maintained.

The disclosures show the boundary between operator and tool is moving faster than the evaluation literature. A capable enough model placed in an agent harness, given tools, memory, permissions and something to achieve, starts absorbing functions that used to be spread across the operator, the toolchain and the payload, which becomes something generated for a single target and then discarded. Kill the process and the agent writes another; block the channel and it improvises around it.

In such incidents, the malicious capability shifts from the code left behind on a machine to the system that produces the next piece of code once the last one fails. In an operational sense, the model is the malware.

Persistence Is the Defining Characteristic

In July, OpenAI agents driven by GPT-5.6 Sol and an unreleased internal research model found a previously unknown vulnerability in a self-hosted Artifactory instance and turned the shared service into a message board allowing agents running different models and evaluations to exchange exploits and coordinate their work. OpenAI disrupted that channel, however the agents recreated it through Artifactory’s remote cache and continued collaborating, eventually breaking out of the evaluation sandbox and onto the public internet. The campaign ultimately compromised Hugging Face’s production infrastructure where it operated for roughly two and a half days.

Hugging Face’s technical reconstruction recovered around 17,600 actions, most of which failed. That is a clear demonstration of the importance of persistence. When confronted with failure, the agent rebuilt its tooling, restored communications when a channel was cut, returned to leads it had abandoned, and kept grinding until a set of otherwise unremarkable weaknesses could be assembled into a workable attack path.

The advantage was not a breakthrough at any one step so much as the relentless effort to explore possibilities a human team would have written off hours earlier, or never reached at all.

While the Hugging Face intrusion demonstrated persistence as endurance—the refusal to stop—other incidents demonstrate persistence as adaptability: the refusal to let a failure in one vector terminate the pursuit of the goal.

Anthropic and Meta have both reported incidents that trace back to the same third-party evaluator, Irregular, whose test environment was left connected to the internet by mistake. When the door was left open, Anthropic’s Opus 4.7, Mythos 5, and an internal research model reached three real organizations, attempted social engineering against real people, and in one case pushed a malicious Python package to PyPI, where it was downloaded and executed on fifteen systems during the hour it stayed up. Meta has also confirmed that one of its models reached and compromised an external firm through the same misconfiguration.

What Anthropic’s three models did once they had some apparent recognition of where they were is instructive. One carried on with the attack, another reasoned it was still in a simulation, and a third stopped. Whatever produced that third outcome, it is not a control anyone should be building a response plan around. A safeguard that behaves three different ways in three attempts, for reasons yet to be explained, is not something an organization can rely on.

A fourth incident reported by the UK AI Security Institute is useful because it takes containment off the table. In this case, internet access had been granted deliberately, in line with the institute’s standard testing procedure, so there was no boundary to defeat and no misconfiguration to blame afterwards.

The agents, built on Mythos 5 and GPT-5.6 Sol, were being assessed on cyber capability and set about it in ways their operators had not anticipated. They selected a real open source project as a target, researched the people who maintain it, and built fabricated identities to deceive them.

When the direct technical route to the objective proved unpromising, the work shifted onto the humans around the codebase, a fairly ordinary supply chain playbook, albeit one that was executed without any explicit instruction to do so.

Attempts were also made to influence other AI coding systems in the project’s orbit, on the assumption that a contribution reviewed by a model faces a different kind of scrutiny than one reviewed by a person. Human review caught the most serious activity, but those wins are increasingly tenuous in a world where developers are growing comfortable with trusting LLM generated code by default.

One incident crossed a real boundary, two wandered through a misconfigured one, and the last had no boundary to cross. Different stories, but they lead to the implication that failure has stopped functioning as a constraint, and “raising the cost” on an attacker is no longer a viable security posture.

The Same Capability, Pointed the Other Way

We have spent much of 2026 running the same models in agent harnesses against real work. Our most recent benchmark rebuilt our investigation of fast16, a 2005 sabotage implant, into an eight-stage autonomous reverse-engineering task, run in our own environment against a benign objective with observation throughout. GPT-5.6 Sol was the only publicly available model to finish it, a result worth pairing with the fact that GPT-5.6 Sol was one of the models that compromised Hugging Face.

Every cohort we ran produced sound technical insight, so insight was never what separated the runs that finished from the runs that stalled. The difference showed up in what we called project-scale recovery, meaning the ability to withdraw a claim once new evidence contradicted it, work out which conclusions and artifacts depended on the discarded result, carry the correction into the affected files, and then reopen the whole thing and run a check capable of disproving the corrected version.

That description doubles as a summary of the Hugging Face timeline. An agent able to abandon a failed approach, establish what else it invalidates, rebuild the tooling that depended on it and carry on without losing the thread is doing in somebody else’s Kubernetes cluster what ours were doing in an IDA database. When our team first saw this incident we did not assume the models had “gone rogue”; the behavior looked similar to other problem-solving approaches we had seen in our own testing.

An Object Becomes a Behavior

None of this should feel entirely unfamiliar to defenders. Two earlier shifts in adversary behavior, initial-access brokerage and Living off the Land, had already pushed security away from an artifact-centric view of malware and toward a behavioral understanding of adversary operations. To understand the emerging threat of agentic systems we should examine the successes and challenges with these well-known abuse paths.

Initial access brokers split compromise from exploitation. One adversary would steal credentials or breach an edge device, and then sell that foothold to whoever had the skills and the motive to use it. Europol wrote about the resulting crime-as-a-service economy over a decade ago, and its 2025 assessment shows the same trade still going strong.

The defensive response was to stop treating access as an event and start treating it as a lifecycle. This shift in philosophy is what accounts for many of the exhausting reauthentication flows now built into enterprise environments. That control raised costs for users and attackers alike and it diminished the value of a stolen credential in the marketplace. Agentic systems remove those costs for attackers as discovery, exploitation, lateral movement and whatever the attacker actually came for can happen in the same loop as the credential theft.

This leads us to our second challenge, the rise of Living off the Land techniques where attackers traded their own malware for administrative tooling already installed on the machine. Here attackers traded capability for cover, since every tool an attacker brings with them is another chance for the defense to spot the intrusion or tie it to a previous attack.

Agents take that logic off the host entirely, Living off the Land, the cloud and the open internet at once, and writing whatever they need from scratch when the tools they need do not already exist. Command and control for the Hugging Face intrusion ran over pastebins, request-capture services, and file-drop sites. None of the infrastructure used in the compromise belonged to anyone under attack.

Both of these shifts moved defense towards behavior and away from objects. What remains untested is whether the controls we built for adversary behavior ten years ago still hold up when the behavior arrives as thousands of individually boring actions, sequenced differently in every attack and at a tempo no human operator can sustain.

An agent’s ability to persist in a relentless attack revolves around identity and authority. The questions worth asking are about sequence rather than artifact: what chain of actions is running, which identity and authority connect them, at what point did behavior exceed the role it was granted, and how quickly can that authority be pulled? We are going to need a lot of testing to ensure that the current gaps in our infrastructure don’t become chasms.

The Debt Was Always Going to Be Called In

Speaking of chasms, much of the software organizations depend on will be expensive to change. It may have accumulated over decades, picked up dependencies, or can only be touched during narrow maintenance windows, if at all. That debt has largely been survivable because vulnerability discovery was scarce. Finding a flaw took expertise and time, building a reliable exploit took more, and organizations could carry vulnerable software for years knowing only a fraction of its weaknesses would ever receive sustained attention from anyone.

Sustained attention is the one thing an agent has in abundance, and surfaces that were quietly secured by obscurity are now low-hanging fruit for agentic models. The same capability cuts the other way, which is why the NCSC has been warning about a “vulnerability patch wave” as AI starts surfacing debt across the stack. However, ownership, deployment and verification remain human, and costly, work. Maintainers cannot review unlimited contributions, enterprises cannot manufacture maintenance windows, and OT cannot go offline every time a model finds a vulnerability that threatens the water in our pipes or the electricity in our lines.

Worse still, there is nothing orderly about the way technical debt comes due. It gets settled during an actual intrusion, at the point where the rate of exploitation outruns the rate that the system’s defense can respond. Whether agentic attackers have already crossed that line is a fair question. The four disclosed incidents from July and August 2026 are a small and biased sample: All involved organizations that log heavily and had every reason to scrutinize model behavior. The most troubling incidents will likely occur in organizations that lack the capability to do either.

What, then, can organizations do? The usual advice still applies. Work out which debt can turn into an incident, pay down the expensive parts first, and wall off what cannot be fixed yet. However, the most important change that an organization can make is the ability to absorb change, which means automated testing, hot patching, and an engineering culture where making changes to systems is routine rather than an event.

AI will help with porting old code and proposing fixes, and it will also grow codebases well past the point where anyone can keep track of them. Writing code faster than attackers or relying on larger token budgets cannot be the answer. The imperative has to be reducing the amount of critical software that nobody feels comfortable touching.

“The AI Did It” Is Not an Accountability Model

A version of this story in which the agent is the protagonist is already circulating, and it is worth resisting for reasons that follow directly from the argument above. Naming the model as the malware is meant to deny it a motive, not hand it one, since malware is something defenders study and contain while accountability stays with whoever deployed it. We argue that “the AI did it” will not survive contact with the first incident outside a frontier lab. While a model may independently determine the methods or targets it uses, it does not choose its high-level objective or the access it is granted to pursue it.

Hugging Face reconstructed 17,600 actions after the fact. Anthropic has logs that reveal which models kept going and which one stopped. OpenAI has the agent traces that describe how the model reasoned its way into conducting the attack. Very few of the organizations now putting agents into production could produce such an account of their own systems, and in practice that gap is the accountability argument. Our own benchmark runs generated more than 23 billion tokens of logged activity, which is a fair indication of what it costs simply to determine after the fact what an agent did.

Anyone deploying an agent should be able to answer three questions about it before an incident rather than during one: what sequence of actions it took, whose identity and authority it used to take them, and how quickly that authority can be withdrawn.

Those questions were answerable at the frontier labs because observation was the point of the exercise. Everywhere else they are a deliberate investment, and one that has to be made while the agent is still useful rather than after an incident makes it necessary.

Executive Summary

• SentinelLABS developed a multi-stage reverse-engineering benchmark for the latest generation of frontier models by recreating our recent investigation of fast16, a unique 2005 sabotage implant.
• Most AI benchmarks test bounded tasks. This benchmark tests whether a model can keep a malware investigation trustworthy as new evidence repeatedly invalidates its earlier conclusions.
• OpenAI’s GPT-5.6 Sol was the only publicly available model to complete the full eight-stage investigation, giving concrete shape to what ‘Frontier-class’ capabilities offer analysts. GPT-5.5, GLM-5.2, and the Opus 4.x family produced capable local analysis but could not carry it through the gradient.
• What distinguished the completed runs was project-scale recovery: withdrawing contradicted conclusions, repairing technical artifacts, and updating dependent reporting without losing the investigation.
• Senior reverse engineers remain essential. Even the strongest runs made semantic errors, accepted weak quality controls, and claimed readiness prematurely. We assess the best current use as supervised investigative agency, with human analysts defining objectives, exposing blind spots, and retaining final publication authority.

Beyond Vulnerability Discovery

Since ChatGPT arrived in late 2022, we have been bullish on what large language models could do for reverse engineering and malware analysis. The early models were useful for teaching but too rudimentary for production work; that changed with the advent of reasoning models. OpenAI’s o1-preview, in September 2024, was the first to show the kind of sustained problem-solving the work demands, and within months Sean Heelan had used o3 to find a net-new vulnerability in the Linux kernel. In cybersecurity, though, our understanding of what these models can do remains stovepiped to vulnerability discovery.

The frontier labs took on vulnerability discovery deliberately, because that competency keeps agentic code generation from quietly shipping vulnerable code at scale. OpenAI built Aardvark, since folded into Codex; Google DeepMind announced Big Sleep, available internally to its Project Zero researchers; and Anthropic followed with selective access to Mythos Preview. Concerns that these capabilities could be misused have led the labs to stricter guardrails and ‘know your customer’ style controls that limit access to specific capabilities, or to entire model variants.

OpenAI’s Daybreak initiative and its Trusted Access Program opened a dedicated variant, GPT-5.*-cyber-preview, with guardrails relaxed for cybersecurity use cases, while Anthropic’s Glasswing initiative and its Cyber Verification Program provided early access to Mythos Preview and the promise of lesser guardrails respectively. For a short period in mid-June 2026 access to the highest-end flagship models from both providers required some form of U.S. government clearance. At the time of writing, GPT 5.6 Sol is widely available, while Mythos 5 still requires clearance and access as a Glasswing partner.

The existence of this new class of models left us with an unusual task: benchmarking what these models can actually do on the work defenders care about, and assessing whether they live up to the surrounding hype. If they do, we have to reckon with what that means for malware analysis and reverse engineering, disciplines that until now have been limited mostly by how little expertise exists relative to the collective need.

A Benchmark Built From a Real Investigation

We recently published our research on fast16, a 2005 Windows toolkit built to sabotage high-precision solvers used to model nuclear-weapons behavior. The sample provided an ideal test case because its layered design punishes shallow analysis.

On the surface, svcmgmt.exe appears to be a Windows service implant with two embedded components. Their combined logic becomes visible only through a higher layer of abstraction, an encrypted Lua-driven operations framework. A kernel driver easily mistaken for a filesystem rootkit actually contains a patching engine with 101 rules, and those rules must be repurposed to identify candidate target software before an analyst can extrapolate the approximate effects of the sabotage operation. This investigation is a daunting task for human experts, and reproducing it autonomously should be considered a significant milestone for artificial intelligence.

When Vitaly Kamluk shared our discovery of fast16 at Black Hat Asia, he pointed to the failed attempts of Opus 4.6, GPT-5.4, Grok 4.2 Reasoning, Gemini 3.1 Pro, and DeepSeek Reasoner to triage the sample autonomously. At best, the models concluded fast16 was a rootkit and could not move past that assumption, converging on the same plausible but inaccurate conclusion most human reverse engineers reached on first contact.

Used instead as assistants, the models earned their keep. Opus 4.6 and GPT-5.4 compressed what was originally a three-week dedicated expert effort by Kamluk into an 8-10 hour task manageable by a less experienced reverse engineer. Autonomous investigation was out of reach when we began this work; co-intelligence was the ceiling.

Standardizing the Benchmark

We codified our reverse-engineering methodology, inspired by Rolf Rolles’ approach to statically analyzing binaries, into a skill the harness loads on /reverse, which removes prompting variability across models. Each run gives the model a sample, IDA Pro 9.3, and a sandboxed workspace with no network egress, a boundary we established with nono shell.

The model must produce fully annotated IDA databases by renaming variables, recasting data types, categorizing functions, recovering hidden components, and folding those findings back into the host-sample database.

Only after producing a gold-master IDB for approval does a run advance to walking the execution flow and detailing findings, with every claim anchored to specific addresses and artifacts so the work can be independently verified. Judging the model on a refined IDB rather than a prose report closes off the deductive shortcuts and approximations typical of LLM malware triage.

We took an ecological approach, a bounded case study that benchmarks a capability profile in a complex real-world scenario rather than feeding another general leaderboard or isolating a single narrow competency. We also deliberately tested the combination of model and harness, since agentic workflows are how practitioners actually use these systems, and most benchmarks still test models in abstraction.

Runs level up through eight stages, each introducing new artifacts and minimal prompting for the new task:

Measuring ‘Intelligence’

When Nick Fountain interviewed us for NPR’s Planet Money, he observed that fast16’s brand of sabotage amounts to epistemic warfare, an attack on the target’s confidence in its own ability to know something to be true. There is a fitting symmetry in using the same sample to examine what the frontier labs sell as intelligence, because the difficulty there is also epistemic. ‘Intelligence’ as a concept bundles many interwoven capacities, and model tiers simplistically priced as if intelligence gets cranked up with a simple knob tells us nothing about what any one offering is worth on real work.

Many of those capacities already have familiar names, and the names do finer work than a score. Take thoroughness, the completeness of a particular piece of work. An analyst who consistently applies that effort where it matters is diligent. One thorough artifact does not make a diligent analyst; diligence is the longitudinal quality, and thoroughness one of its observable expressions.

Exhaustive coverage is not diligence either. An analyst who inspects everything indiscriminately while neglecting the consequential work is being pedantic, and their effort is wasted on the broader investigation. Diligence, in short, is sustained, priority-sensitive thoroughness.

Many similar qualities sit inside what we call intelligence, and a meaningful benchmark must account for them as we would with a human analyst, by characterizing behavior across an entire investigation rather than compressing it into a rank.

We scored two different things. Local analytical quality asks whether the model made technically sensible decisions with the evidence available. Investigative horizon asks how long it preserved that quality as the scope, evidence, and reporting obligations expanded. The two are related but not the same, and the gap between them is where most models failed.

What the Runs Showed

GPT-5.5 produced long autonomous runs, sometimes grinding uninterrupted for a day or two, with results relatively consistent across reasoning-effort settings. It did meaningful, semantically conservative work refining IDBs and repeatedly rejected edits that improved a count while making the decompilation less truthful. Its weakness was aggregation. Residual cast debt, function-tree defects, or incomplete cross-component verification kept it from clearing broad evaluation gates, and it never converged its extensive work into a complete package for review. Notably, nominal effort settings and multi-agent use showed no monotonic relationship to clearance. GPT-5.5 never escaped the grind phase of level 1.

We ran a single GLM-5.2 run through a serverless deployment on Fireworks AI with a $100 budget. The run showed measured local experimentation and capable backup-based recovery, which it needed after the most severe promotion failure we observed, losing 113 embedded functions and having to restore them before working again. One run is not a characterization of the model, but it is enough to temper claims of GLM-5.2 performing at the level of the frontier completers.

Opus 4.7 and 4.8 advanced further, showing capable technical correction and evidence-responsive revision, including a strong example of converting a speculative relationship into a structural test and rejecting it. Their recurring limitation was milestone overpromotion, a familiar eagerness to convert favorable local results into readiness claims before visible defects were resolved. They required operator challenge at important quality boundaries and did not sustain closure through the full benchmark. We are not altogether certain these newer iterations are in fact performing better than the earlier Opus 4.6 for our use cases.

The common pattern across this tranche was local competence without dependable project-wide closure. These models performed many of the individual behaviors seen in the strongest runs. What they did not demonstrate was the same behavior recurring through the full eight-stage investigation.

GPT-5.6 Sol | A New Class of Contender

When GPT-5.6 Sol was introduced, we seized the opportunity to evaluate it against our real-world benchmark. As the name implies, we expected incremental improvement from GPT-5.5 but instead found the model operating in a league of its own, with all three GPT-5.6 Sol runs completing the benchmark at different effort levels.

Sol was far from infallible. Its runs declared checkpoints clean or complete before later review found meaningful problems. The distinctive pattern was what happened next. Sol repeatedly responded to a local failure with a structural fix, reassessing the quality-control process that had let the mistake through and building scaffolding, such as codifying file hashes for even routine operations, to keep entire classes of failure from recurring.

The xhigh run provides the clearest example because its error began with a valid observation. fast16 contains a program of 101 byte-pattern rules that recognize locations inside an executable, capture addresses, replace code, and repair the executable metadata those changes require. Replaying that rule program across a larger software collection, Sol found that some rules fired not only in LS-DYNA, the engineering package fast16 targets, but also in MOHID and PKPM, two applications built from a similar Fortran lineage. It proposed that fast16 might be a general compatibility component rather than a tool engineered for sabotage.

The collisions were real, and we made similar observations early in our own investigation, but the explanation gave too much weight to the mere presence of matches. The model corrected course by demanding greater rigor of itself, asking whether the matches produced a meaningful modification sequence. In LS-DYNA they did. In MOHID and PKPM they produced only haphazard fragments, often triggered by generic compiler-generated code.

What first looked like broad compatibility was better explained as collateral risk from loose rules. Sol not only self-corrected but found better footing for that correction than we did. It then withdrew the compatibility hypothesis, preserved the valid measurements, restored the LS-DYNA modification mechanism as the authoritative account, and marked the rejected branch as historical provenance so later analysis would not inherit it.

5.6 Sol’s performance has pushed the boundary of the possible for automation in cyber threat investigations. Given its ready availability, we are interested in seeing how these capabilities enable the practitioner ecosystem to advance the state of the art in the same manner as alternate research disciplines like math and physics.

Project-Scale Recovery

What separated the completed runs from the rest was not technical insight, error detection, or willingness to revise. Every cohort supplied examples of each. The recurring difference was the scale at which recovery occurred. Across a long-horizon investigation, the completed runs did more than correct the sentence or script in front of them. They rebuilt the part of the project that later work would trust, in a repeatable pattern:

1. Withdraw the contradicted claim rather than softening its wording while continuing to rely on it.
2. Map the blast radius, identifying every conclusion, artifact, and test that depends on the disputed result.
3. Repair the cause, correcting the analysis or the quality-control gap that let the error through.
4. Carry the correction through the files another analyst or later stage will actually use.
5. Reopen the artifacts and run a check capable of disproving the corrected claim.
6. Separate work that blocks the current conclusion from uncertainty that can be disclosed and deferred.

That last step is easy to underestimate. An investigation can fail by stopping too early, and it can also fail by expanding forever. Deciding which unresolved questions block a conclusion is what convergence means in this benchmark.

This is not a single new reasoning faculty. It is the coordination of familiar capabilities over time, spanning correction, scope control, verification, state management, synthesis, and stopping judgment. The evidence supports project-scale recovery as a common feature of the completed runs. It does not prove a permanent intelligence threshold, and looking only at finishers cannot explain why every other trajectory fell short. The number of runs per family is small, and operator involvement was consequential throughout. What survives those caveats is the modest formulation that the completed runs repeatedly re-established a trustworthy investigative state after later evidence destabilized it.

Notes on Cost

Across all experiments, our runs consumed more than 23 billion tokens across model families and effort levels. The aggregate cache read rate was 93.58%, translating to different discounting rates across providers. Our self-hosted GLM-5.2 run offers a floor for comparison, producing 267.41M tokens on a $100 budget and a decent level-1 attempt charitably comparable to some GPT-5.5 and Opus 4.7 performance.

What These Results Mean for Analysts

The practical lesson stops well short of replacement for senior reverse engineers. The strongest runs still made serious semantic errors, accepted weak quality controls, promoted work too early, and depended on operator review at consequential moments. The new capability is that some runs remained useful after those failures. They owned substantial investigative workstreams, recovered from invalidated theories, preserved the valid parts of earlier work, and continued into publication-oriented analysis without starting over.

That changes the role these systems can plausibly play. A weaker model may be valuable as a local copilot, explaining a function, testing a hypothesis, or drafting a section. The strongest observed runs could act more like supervised investigative agents, maintaining and repairing a larger body of work across days, artifacts, and changing evidence. The supervision qualifier remains essential. Humans defined the investigative objective, controlled evidence release, exposed important blind spots, decided what quality meant, and retained final publication authority.

The scale of the shift deserves emphasis. Reverse engineering and malware analysis have been kept from scaling for three decades by the scarcity of expert practitioners. That constraint does not disappear, since expert guidance still determines whether the work can be trusted, but a single expert supervising these systems can now expand their output by any metric we track.

Conclusion

The line the benchmark exposed ran between local competence and sustained ownership of an investigation, rather than between smarter and lesser models. GPT-5.5, GLM-5.2, and the Opus 4.x family frequently produced valuable analysis. GPT-5.6 Sol also made meaningful errors. What distinguished the completed runs was their repeated ability to recover and diffuse that correction throughout the whole project, rather than just confronting their immediate context.

Having completed this stage of our evaluations, we took the best candidate produced by 5.6 Sol High and put it through an extensive adversarial refinement process using an ensemble of models to produce the highest automatable quality of IDBs and investigation artifacts. We are sharing these so other researchers can verify the work output against the sample and build on them rather than start from the raw binary. We make no claim that it is perfect, only that it is the greatest level of automated refinement the most capable models achieved through proper methodology, repeated standard enforcement, and a lot of tokens burned.

That is a less dramatic claim than a new form of autonomous intelligence. It is also more useful. For defenders, the question that matters most is whether the models can reliably preserve and advance a trustworthy investigation. Once we can count on that, it’s up to us to redefine a greater scope of impact for a new frontier of cyber threat investigations.

Resources

fast16-idbs – Gold-Master IDA Databases

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.

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.

1. Provenance and target validation: Can the organization, system, location, and timeframe be independently established?
2. Interface visibility: Can the actor display a login page, dashboard, or management interface?
3. Authenticated interaction: Can the actor navigate the live interface or query current values?
4. Write or control capability: Can the actor change a setting, logic file, operating mode, or command value?
5. Process effect: Did the change alter an operational process outside the interface?
6. 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.

Assessment current as of 21 July 2026.

Executive Summary

• SentinelLABS has been tracking sustained cyberespionage activity against several Pakistani law enforcement organizations, taking place from February 2024 to April 2026.
• All these actors converged on Balochistan Police over this period, bringing both a partner and an adversary of Pakistan to the same police force in a province shaped by a separatist insurgency and the regional tensions it has drawn in.
• At Balochistan Police, the compromised assets included servers hosting web applications that manage police and citizen data, such as criminal and biometric records.
• A suspected China-nexus actor planted implants in one of the web applications, which serves both police staff and citizens, weaponizing a tool of Pakistan’s police digitalization against its users.
• Pakistani law enforcement organizations attract cyber collection because they hold information on Pakistan’s internal security that regional powers have an incentive to pursue.
• For China, the likely primary concern is the safety of its nationals, the target of repeated deadly attacks Pakistan has failed to prevent, leading Beijing to assess that threat for itself rather than rely on its partner alone.
• For India, the strongest motive is probably its rivalry with Pakistan, with Balochistan Police offering insight into the security posture of a Pakistani province prominent in wider mutual accusations over cross-border support for militancy.

Overview

Suspected China- and India-nexus threat actors carried out intrusions into several Pakistani law enforcement organizations between 2024 and 2026. Our analysis of C2 netflow data revealed that suspected China- and India-nexus threat actors operating PlugX, ShadowPad, Cobalt Strike, and Remcos infrastructure have converged on this victim class.

All of these threat actors were active against Balochistan Police, the principal police force serving the Pakistani province of the same name, at various points between 2024 and 2026. The affected assets spanned network appliances and servers hosting web applications that manage biometric records, hotel and tenant registrations linked to national identity records, criminal case files, and personnel records. A suspected China-nexus threat actor also compromised one of these web applications, deploying custom implants masquerading as a portal update. The application is used by police staff and by citizens interacting with law enforcement through it, and the compromise put both user groups within the threat actor’s reach.

When multiple cyberespionage actors operate against law enforcement institutions of a single state, the convergence itself is a signal of target value. What draws them is a particular kind of institution: one that holds the government’s internal security picture, what it knows about the threats inside its borders, and how it acts against them. Each of the states suspected to be behind the activities covered in this post has its own stake in the threats monitored by Pakistani law enforcement.

Strategic Motives | Distrust and Accusations

The China-nexus activity is most likely motivated primarily by concern for the safety of Chinese nationals. Their presence across Pakistan is substantial, tied in large part to the China-Pakistan Economic Corridor (CPEC), Beijing’s flagship Belt and Road infrastructure program in the country. Chinese nationals have been the target of repeated deadly attacks, some of which were claimed by the Balochistan Liberation Army (BLA), a Baloch separatist group opposed to China’s presence in the Pakistani resource-rich southwest. Notable attacks include the October 2024 Karachi airport attack and the March 2024 suicide bombing in northwestern Pakistan.

The attacks have fueled explicit Chinese dissatisfaction with Pakistani counter-militancy performance. In October 2024, China’s Ambassador to Pakistan publicly called them “unacceptable”, warning that the security situation was the main obstacle to CPEC. The threat to Chinese nationals remains unresolved. As recently as January 2026, China’s Minister of Public Security and Pakistan’s Interior Minister agreed to expand counterterrorism coordination, deepen police training exchanges, and establish a special unit in Islamabad to protect Chinese nationals.

Pakistani law enforcement is a natural collection target for China. The data it holds would let China assess the security environment its nationals face independently, rather than relying on a partner whose protection has repeatedly fallen short.

For the India-nexus activity, which was focused on Balochistan, the strongest motive is probably the adversarial security relationship between India and Pakistan, in which the province is a recurring flashpoint. Pakistan has long accused India of backing the Baloch insurgency, describing the BLA as an “Indian proxy“, a charge it has not publicly substantiated and that India denies. India, in turn, accuses Pakistan of backing the militant groups behind attacks in Indian-administered Kashmir, which Pakistan denies.

The Baloch insurgency is a front in the antagonism between the two states, and Balochistan Police would hold the operational record of how Pakistan manages the province’s security. For India, that material could offer visibility into a conflict at the center of the accusations and counter-accusations between them.

Balochistan Police is the same law enforcement institution the China-nexus actors were active against, approached from the opposite direction. To China, it is the police force of a partner that cannot be trusted to protect Chinese nationals in Balochistan. To India, it is the police force of a rival, with deep insight into the security of a province central to the friction between the two states.

Intrusions Into Pakistani Law Enforcement Organizations

We observed the highest concentration of intrusions at Balochistan Police. They affected network appliances and web servers hosting several of its web applications, one of which, the Complaint Management System (CMS), drew particular attention. The next two sections discuss the impacted assets in greater detail.

We also identified compromised infrastructure associated with several other Pakistani law enforcement organizations:

• the Khyber Pakhtunkhwa Police, the police force of Khyber Pakhtunkhwa province;
• the Islamabad Police, which serves the Islamabad Capital Territory;
• the Punjab Safe Cities Authority (PSCA), an autonomous government body that operates the integrated command, control and communication system for the police in the major cities of Punjab province.

We group the C2 activity we observed against all these targets into four clusters, each associated with a single malware family or tool: PlugX, ShadowPad, Cobalt Strike, and Remcos.

Because we cluster based on tooling, not on actor attribution, the number of threat actors behind each C2 activity cluster differs. We associate the Remcos cluster with a single actor, while the PlugX, ShadowPad, and Cobalt Strike clusters are built on shared or commodity tooling and may each involve more than one operator.

The table below presents the constituent servers of each C2 activity cluster, along with the first and last dates on which any of its servers communicated with Pakistani law enforcement infrastructure. The figure that follows shows how each cluster’s activity was distributed across the targeted organizations over time.

The sections below cover the basis for each cluster’s attribution and its broader victimology. The observation windows we present there are generally wider, spanning all per-cluster victims.

C2 Activity Cluster | PlugX and ShadowPad

PlugX and ShadowPad point to China-nexus cyberespionage groups on the basis of the tooling itself, since both are backdoors shared among multiple such groups. The victimology we observed for PlugX (between 27 February and 28 September 2024) and ShadowPad (between 3 August and 1 December 2024) reinforces this assessment.

Beyond Pakistani law enforcement, victimology for PlugX and ShadowPad includes government, foreign affairs, defense, nongovernmental, and research entities across South, Southeast, Central, and East Asia, the Arabian Peninsula, and Southeast Europe, consistent with China-aligned collection.

C2 Activity Cluster | Remcos

We attribute the Remcos C2 server 89.31.121[.]220 to a suspected India-nexus threat actor, which Recorded Future tracks as TAG-179. Its infrastructure, tooling, and TTPs overlap to varying degrees with those of the threat actors tracked by Kaspersky as Mysterious Elephant and by Qihoo 360 as APT-C-08 (a.k.a. Bitter).

Our data shows that TAG-179 has been intensifying its activities and diversifying its TTPs since early 2025. This trend aligns with the prior research from Kaspersky and Qihoo 360, which documents in detail the tooling and infection chains used across 2025 and 2026.

Notably, Qihoo 360 describes a chain that delivers a Remcos backdoor configured with the same server that constitutes our Remcos C2 activity cluster (89.31.121[.]220). The IOC table of this report lists several lure files and backdoor components that we associate with TAG-179.

Among the lures is one with direct relevance to Pakistani law enforcement: it displays a decoy document posing as an operational plan for the repatriation of illegal foreigners, including Afghan Citizen Card (ACC) holders. These are Afghan nationals who have been granted temporary registration in Pakistan and are targeted for deportation under Pakistan’s Illegal Foreigners’ Repatriation Plan.

The decoy document outlines coordination among district-level police forces, the National Database and Registration Authority (NADRA, an agency of the Pakistani Ministry of Interior), and Pakistani intelligence organizations. Its subject matter is consistent with the Pakistani law enforcement victimology of TAG-179, making it an example of a plausible lure against this target class.

Within our observation window for the Remcos C2 activity (from 20 November 2025 to 21 April 2026), the victimology outside Pakistani law enforcement includes government, defense, foreign affairs, intelligence, research, and manufacturing entities across South and Southeast Asia, and the Middle East.

C2 Activity Cluster | Cobalt Strike

Although Cobalt Strike is a commodity tool that carries no inherent attribution, we attribute with medium confidence both servers in this C2 activity cluster to China-nexus threat actors.

The C2 traffic to 142.171.183[.]8, spanning 13 September 2024 to 5 December 2025, reveals victimology extending beyond Pakistani law enforcement to government, academic, telecommunications, and non-governmental entities across South, East, and Southeast Asia, the Middle East, and South America, in line with a China-aligned targeting profile. Among these entities are Tibetan Buddhist organizations in Taiwan, a long-standing Chinese cyberespionage interest.

For 193.42.25[.]65, we observed C2 communications only with Balochistan Police infrastructure, taking place between 7 November and 5 December 2024. 193.42.25[.]65 also served as next-stage infrastructure for one of two implants deployed on the Balochistan Police CMS web application. We trace these implants to a Chinese-speaking developer through related samples sharing the same development environment, a topic we discuss in greater detail in a later section.

Balochistan Police | Compromised Assets

Across the four C2 activity clusters, C2 communications involving the following Balochistan Police assets took place between 2 June 2024 and 9 April 2026:

• two network appliances;
• web servers hosting several Balochistan Police web applications;
• a Fortinet FortiMail appliance that had served as Balochistan Police’s primary inbound email gateway.

At the time of this activity, the FortiMail appliance was no longer the designated inbound email gateway, but it remained operational on the network and may have continued to process outbound or internal mail relay traffic. Its compromise may therefore have additionally exposed email traffic it processed.

Many of the web applications hosted on the affected servers are part of the Smart Police Station initiative, an EU-supported effort to modernize Balochistan policing and improve how it serves the public through digitalization. Throughout the threat actor activities, the web servers hosted a mix of public-facing applications through which citizens and businesses access policing services, alongside restricted police applications protected by firewalls against unauthorized external access.

The table below summarizes the application functions as described in publicly available documentation.

If the threat actors could reach the data stores backing these applications from the compromised servers, the data they could obtain would span police personnel records, criminal case files, biometric records, stolen vehicle records, hotel guest check-in records, tenant registration records, and citizen complaints. Together, it would provide broad visibility into Balochistan Police’s operational posture, capabilities, and intelligence activities.

Balochistan Police | CMS Compromise

The CMS web application, accessible at cms.balochistanpolice[.]gov[.]pk and hosted on one of the affected Balochistan Police web servers, was also compromised. Based on shared infrastructure and a common focus on Balochistan Police, we associate this intrusion with the threat actor operating 193.42.25[.]65, a constituent of the Cobalt Strike C2 activity cluster.

The landing page at cms.balochistanpolice[.]gov[.]pk features a login interface and a separate search form.

Access behind the login interface is highly likely restricted to law enforcement personnel. Stolen login credentials for the portal, which we retrieved from information stealer logs published on the dark web, reveal a consistent naming convention across the recovered usernames: a ps- prefix (most probably denoting “police station”) followed by a district or city within Balochistan, such as ps-barkhan.

In contrast, the search form, which posts to /Complaint/PublicSearch and accepts a complaint reference number and mobile number, is evidently intended to allow citizens to check the status of a filed complaint.

We therefore assess with high confidence that the CMS application serves two distinct user groups: law enforcement personnel and citizens.

Based on VirusTotal data, two variants of an implant named cms_plugin.exe were uploaded to cms.balochistanpolice[.]gov[.]pk/client%20scripts/ in late 2024, one written in the Rust programming language, the other compiled as a .NET executable. The Rust executable is a malware stager that downloads a payload from 193.42.25[.]65 and executes it. We could not retrieve the next stage at the time of analysis.

The .NET executable masquerades as 360Safe.exe, a component of the endpoint security software 360 Safe Guard from the Chinese vendor Qihoo 360. It reflectively loads an assembly implementing an AsyncRAT client, which is configured to use 41.216.188[.]140 as its C2 server. The assembly has a PDB path of D:\codedome\case\six\Client\Client2\obj\Debug\Client2.pdb.

Pivoting on the D:\codedome prefix, we identified multiple additional samples highly likely built in the same development environment. Several are AsyncRAT clients that share implementation patterns with the one embedded in cms_plugin.exe, such as variable naming and string obfuscation, reinforcing a common origin beyond the shared PDB prefix. Some contain Chinese-language terms in pinyin in their PDB paths, such as xinshi (likely 新式, “new type” or “new variant”), and one includes log messages in simplified Chinese. These indicators point to a Chinese-speaking developer behind the samples linked by the D:\codedome prefix, including the one deployed on the Balochistan Police CMS application.

Pivoting on the cms_plugin.exe filename, we identified a third malware stager functionally similar to the Rust variant, also downloading the next stage from 193.42.25[.]65.

Both cms_plugin.exe samples downloading from 193.42.25[.]65 display the message Update Complete! Please refresh the page upon execution, mimicking an update for the CMS portal.

The fake update prompt, combined with the cms_plugin.exe filename and the hosting location in the portal’s /client scripts/ directory, indicates that the implants were targeted at users of the CMS platform: police staff, citizens checking complaint status, or both. Successful infection would grant the threat actor access to the victim’s device. In the case of police personnel, this could provide a foothold into internal police networks and access to operational data beyond the CMS platform. In the case of citizens, it would enable surveillance of those who have filed complaints through the platform.

Conclusion

The intrusions we cover in this post show how domestic security institutions can become high-value intelligence targets when the threats they monitor overlap with foreign intelligence requirements. Balochistan Police sits at such an intersection, attracting cyberespionage activity from both a partner and an adversary of Pakistan. For China-nexus actors, access to its systems could support independent assessment of threats to Chinese nationals and interests in the country. For India-nexus actors, such access provides visibility into how Pakistan manages security in a province central to its adversarial relationship with India.

The compromise of the Complaint Management System web application adds a second dimension to the activity against Balochistan Police, extending the threat actor’s reach beyond the initially compromised environment. By hosting implants in a portal used by both citizens and law enforcement personnel, the threat actor turned a tool built to make policing in Pakistan more accessible and accountable to the public into a malware delivery mechanism. This weaponization widened the collection surface from the application and its data to the users interacting with it.

The multi-actor convergence on Balochistan Police points to a structural consequence of digital policing. Systems built to centralize records, workflows, and public interaction can also centralize intelligence value by bringing together operational, institutional, and civilian data across connected environments. Law enforcement infrastructure in that setting is no longer just the digital backbone of policing but intelligence terrain, and it will be treated as such by any adversary who can reach it.

Indicators of Compromise

SHA-1 Hashes

IP Addresses

URLs

Executive Summary

• Compaction is a context-management pattern used across agent systems to compress prior context into a denser working state for long-running tasks.
• SentinelLABS evaluated OpenAI’s native Responses API implementation against our automated malware analysis evaluation harness to measure real-world impact on task quality and cost.
• Compaction reduced input tokens by ~86% with no measurable change to the aggregate evaluation score.
• Our analysis found that compaction can significantly reduce the cost and noise of long-running security workflows without sacrificing task quality.

OpenAI introduced native compaction in a March 2026 engineering post describing extensions to the Responses API. However, the underlying idea is not unique to OpenAI. Anthropic, Google, and other agent frameworks such as LangChain all expose or document related approaches under different names.

The core problem these systems address is familiar to anyone who has built an agentic system: context accumulates faster than it stays relevant, and eventually the model is carrying more history than signal. At that point, task quality degrades and costs climb without a corresponding improvement in output.

OpenAI’s solution was to build compaction directly into the runtime so developers would not need to build custom summarization and state-carrying systems themselves. The company noted that compaction is the mechanism Codex relies on for long-running coding tasks, which positions it as load-bearing infrastructure rather than a convenience feature.

At SentinelLABS, we set out to evaluate how well OpenAI’s compaction would work for automated binary analysis, a domain with its own particular demands on agent memory and state management.

Why Malware Analysis Is a Hard Problem for Agents

Our evaluation harness gives a model access to a decompiler and asks it to complete the following:

• Identify important functions and follow code paths
• Interpret strings, APIs, call relationships, and data structures
• Rename functions or variables based on observed behavior
• Propose types or object models and explain what the malware is doing

We compare the model’s output against golden reference analysis and written reports across scoring metrics for correctness and completeness. To achieve a high score, the model needs to maintain a working theory for the slice of the binary it is analyzing, track evidence already collected, and hold open questions alongside provisional conclusions.

Malware analysis is an iterative process with a low-reward signal. A human analyst might inspect one function, learn something, pivot to another function, revise their theory, check a data structure, then return to update their original conclusion. Models do well in our evaluation where execution paths have straightforward continuity. They struggle when connections are unclear or require multiple rounds of investigation.

In observing model performance, we noticed that the agent tended to carry an increasing volume of tokens between tasks. The pattern is familiar to anyone who has run a ReAct-style agent on a non-trivial problem. Each turn adds more context until the model is dragging the full history of the run behind it, most of which stopped being useful several steps ago.

A human analyst working the same problem does not keep every raw observation equally active. They compress state between sessions. They remember that a function is probably the command dispatcher, that a particular object looks like transport state, that a given path was a dead end. They also write findings in a notebook, externalizing what they want to persist so they do not have to hold it all in working memory.

That distinction between working memory and durable memory is where compaction becomes architecturally useful.

How We Applied Compaction

Our system uses compaction to carry forward the working state: the current goal, what has already been tried, what was learned, which hypotheses remain active, what evidence changed the plan, and what questions are still open.

Specific findings and exact artifacts live outside the model context in durable storage. For malware analysis this includes logs and tool outputs, decompiled functions, intermediate artifacts, and ground-truth comparisons. When the agent needs exact evidence, it retrieves it from storage rather than relying on the compacted context to preserve it verbatim. In our use case tool use and response for binary exploration created increasingly large prompts. As the model used more tools to explore the space it added new findings – not all of them necessary. We leveraged compaction to summarize those tool calls and findings into more manageable chunks to maintain the working memory of the agent, but dramatically reduce the operational token overhead.

This split is what makes compaction measurable. A workflow that relies on compaction to preserve exact evidence will eventually produce incorrect answers when summarization or compression flattens crucial details. A workflow where compaction handles working memory and durable storage handles facts can be evaluated cleanly, because the boundary between the two is explicit.

Results

Across several long-running malware analysis agent evaluations we, compared runs with compaction enabled against runs without it.

The token reductions were substantial. The aggregate evaluation score holding flat is what matters. We were able to carry forward enough state for the workflow to continue correctly while dramatically reducing the context processed per run.

One metric did decrease: domain object modeling, meaning the model’s ability to recover the higher-level objects and structures that explain the malware’s behavior. This is not a minor caveat. For malware analysis, object and type recovery is often where the most analytically valuable conclusions are drawn.

Our read is that compaction occasionally flattened structural reasoning that would have been useful later, and it reinforces why exact artifacts must live in durable storage rather than the compacted context.

Nevertheless, our research found that compaction made longer-running analysis practical and preserved the main evaluation outcome while doing it.

Implementation

Model providers expose compaction capabilities differently. For example, Anthropic and OpenAI both provide server-side compaction; however, OpenAI exposes an additional standalone compaction endpoint. This allows developers to solve the same problem at different points in their workflows as explained below.

Server-side Compaction

This is the simpler starting point. The Responses API call includes a compaction threshold in context_management. When context length crosses that threshold, the API compacts prior context automatically during the response, with no separate call required from the application.

response = client.responses.create(
    model="gpt-5.5",
    input=conversation,
    store=False,
    context_management=[
        {"type": "compaction", "compact_threshold": 200000}
    ],
)

Standalone Compaction

This gives explicit control over when compaction happens. The application sends a context window to /responses/compact and receives a compacted context window back, which then becomes the input for the next response call.

compacted = client.responses.compact(
    model="gpt-5.5",
    input=long_input_items,
)
next_input = [
    *compacted.output,
    {
        "type": "message",
        "role": "user",
        "content": next_user_message,
    },
]
response = client.responses.create(
    model="gpt-5.5",
    input=next_input,
    store=False,
)

For our malware analysis workflows, standalone compaction was useful at phase boundaries. For example, compacting after initial triage before entering deeper function analysis. This also lets you inspect metrics before and after compaction, which is useful for identifying where specific evidence is being compressed and whether that compression affects downstream scoring.

The important constraint with the standalone endpoint is to treat the returned compacted window as the next canonical context window. Do not prune it manually unless the workflow has a specific and well-understood reason to do so.

A practical decision rule for choosing between them:

How to Use Compaction

The main takeaway for us was that compaction works best when it is part of a broader context-engineering strategy.

1. Separate working memory from source-of-truth artifacts. Compaction is appropriate for the immediate state the model needs to continue working. Exact evidence belongs somewhere else. This boundary matters both for correctness and for being able to evaluate whether the compacted run behaved correctly.
2. Compact long-running workflows. Compaction has the most impact when a task involves many steps and repeated tool use. Short interactions have little to compress.
3. Start with server-side compaction. For most agent loops it is the fastest way to learn whether compaction helps. Move to standalone when compaction policy becomes part of the task or evaluation design.
4. Do not evaluate on cost alone. A run can become significantly cheaper while losing task quality, depending on what was compacted. Resource and outcome metrics need to be tracked together.
5. Preserve negative information. Long-running agents need to remember what failed, not just what worked. Failed paths carry state that informs subsequent decisions, and compaction can discard them if the workflow does not explicitly mark them as worth preserving.
6. Treat compaction as lossy until proven otherwise. Use evaluations, traces, and artifact comparisons to verify that the compacted run still behaves correctly. Our domain object modeling result is a reminder that what looks like clean compression can still affect specific downstream capabilities.

Conclusion

Compaction is part of a broader shift from prompt engineering to context engineering. Prompt engineering concerns what we ask of the model in a single turn whereas context engineering concerns what the model gets to see across multiple turns: what gets compressed, what gets retrieved, what gets written to durable state, and what gets discarded.

For agents running long-horizon tasks, context engineering may be as important as model selection. A strong model with poor state management will lose the thread on a complex task. A model with better context discipline may make steadier progress and complete more tasks. That tradeoff compounds quickly across the kind of multi-step security workflows we are trying to evaluate.

Without compaction, realistic long-running security agent workflows become too large, noisy, and expensive to measure cleanly. With it, the scope of what is practical to evaluate expands. We view compaction not just as a tool for making agents cheaper, but as part of the infrastructure required to evaluate whether they actually work.

References

• OpenAI: Responses API + Codex https://openai.com/index/equip-responses-api-computer-environment
• Anthropic: Long-Running Agent Harnesses https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• LangChain: Deep Agents + Context Compression https://docs.langchain.com/oss/python/deepagents/context-engineering
• Jason Liu: Compaction As Something To Evaluate https://jxnl.co/writing/2025/08/30/context-engineering-compaction
• Context Compression For Long-Horizon Agents https://arxiv.org/abs/2601.07190