The ransomware operation known as INC has grown into one of the most active cybercrime groups of 2026, with security researchers linking it to more than 830 victims since it first appeared in August 2023.
According to researchers at Acronis, the group's rise coincided with disruptions affecting major ransomware brands such as LockBit and BlackCat. As affiliates sought alternative platforms, INC appears to have benefited from that shift. More than 65% of the victims listed by the group are based in the United States, with legal firms, healthcare providers, manufacturers, construction companies, and technology organizations among the most frequently targeted sectors.
Researchers also observed major changes to the ransomware itself. INC's malware for Windows and Linux/VMware ESXi systems has been rewritten in Rust, a programming language increasingly adopted by malware developers because it supports multiple operating systems and can complicate reverse-engineering efforts.
The group's toolkit has expanded as well. Recent attacks have involved a credential-stealing utility capable of extracting authentication data from newer Veeam backup deployments that use salted DPAPI encryption. Access to backup infrastructure can give attackers valuable credentials while also making recovery efforts more difficult for victims.
Acronis noted that the sale of INC's Windows and Linux ransomware variants on underground cybercrime forums in May 2024 contributed to the appearance of related ransomware families, including Lynx and Sinobi. Researchers identified significant code similarities between the groups.
Investigators found that INC affiliates rely on several entry points to compromise networks, including spear-phishing campaigns, credentials purchased from Initial Access Brokers (IABs), and the exploitation of publicly exposed systems running vulnerable versions of Citrix NetScaler, Fortinet EMS, and SimpleHelp software.
Once inside a network, attackers harvest credentials, move between systems using legitimate administrative tools such as RDP and PsExec, and attempt to weaken security controls through a technique known as Bring Your Own Vulnerable Driver (BYOVD). Researchers observed the use of vulnerable drivers including filwfp.sys, filnk.sys, and fildds.sys. The group also deploys tools such as Cobalt Strike, AnyDesk, ScreenConnect, and TeamViewer to maintain access and control compromised environments.
Before encryption begins, stolen files are collected and transferred using Rclone, often after being packaged into password-protected archives. The ransomware then encrypts systems using multithreading and partial-encryption techniques to speed up the process. When launched against VMware ESXi environments, the malware can also attempt to shut down virtual machines.
Data from ZeroFox ranked INC as the fourth most active ransomware operation during the first quarter of 2026, recording more than 120 incidents. Researchers said the group's growth demonstrates how ransomware operators can build large-scale campaigns using widely available tools, stolen credentials, and unpatched systems rather than relying on highly specialized malware.
![]() |
For years, cybersecurity teams have relied on established methods to determine how dangerous a threat actor might be. Analysts typically examine the techniques an attacker uses, the tools involved, and the complexity of an operation to estimate the level of risk. New research from Anthropic, however, recommends that artificial intelligence is beginning to disrupt those assumptions.
The company's Frontier Red Team recently analyzed 832 user accounts that were removed from Anthropic's platforms for engaging in malicious cyber activity between March 2025 and March 2026. Researchers compared the observed behavior against the MITRE ATT&CK framework, a widely used industry resource that categorizes adversary tactics and techniques. Portions of the findings were also referenced in Verizon's 2026 Data Breach Investigations Report.
It's a signal to keep up with how cybercriminals are using AI. Rather than limiting AI to basic tasks, attackers are increasingly applying it to activities that take place after gaining access to a target environment. This trend suggests that AI is becoming part of deeper operational stages of cyber intrusions, including tasks that traditionally required stronger technical expertise.
Among all observed cases, malware development was the most common use of AI. Researchers found that 560 of the 832 analyzed accounts, representing more than two-thirds of the dataset, used AI-assisted tools to help create or modify malicious software. While this finding was expected, the more notable change appeared elsewhere.
Throughout the study period, researchers recorded a movement away from AI-assisted initial access activities and toward post-compromise operations. One example was account discovery, a process attackers use to identify valid user accounts within a breached network. AI-assisted account discovery increased by 8.9% during the reporting period. By contrast, AI-supported phishing activity declined by 8.6%.
The data also showed growing use of AI during lateral movement operations. Lateral movement refers to the actions attackers take after entering a network to expand their access and reach more valuable systems, users, or data repositories. According to the report, 54 of the 832 observed actors used AI assistance during this stage of an intrusion.
Historically, activities such as account discovery, privilege escalation, and lateral movement have been associated with more experienced operators because they require a stronger understanding of network environments and attack workflows. Researchers argue that AI is reducing those technical barriers, allowing a broader range of actors to perform tasks that were previously more difficult to execute effectively.
This change became visible in the study's risk assessment data. During the first half of the observation period, approximately 33% of threat actors were categorized as medium-risk or higher. During the second half, that proportion rose to 56%. Researchers described this increase as evidence that AI is helping a larger segment of the threat landscape carry out more advanced cyber activity.
The findings also raise questions about how the industry evaluates attacker sophistication. Security teams have long treated the number of techniques used during an attack as an indicator of capability. Anthropic's analysis suggests that this relationship is becoming less reliable in AI-assisted environments.
Researchers found only a small difference between lower-risk and higher-risk actors when measuring the number of techniques used. Less sophisticated actors employed an average of 16 techniques, while the most capable actors averaged 20. The narrow gap indicates that technique counts alone may no longer provide a meaningful way to prioritize threats.
The same pattern appeared when researchers examined how attackers interacted with AI systems. Whether actors used Claude Code, direct API access, or standard chat interfaces showed little connection to their assessed risk level. Simply identifying which AI tool was used did not provide a clear indication of the threat posed by an actor.
Instead, researchers found that the location of AI usage within the attack lifecycle was a stronger indicator of risk. Higher-risk operators tended to apply AI to technically demanding stages of an intrusion, including internal reconnaissance, privilege escalation, and lateral movement. These activities often have a direct impact on how effectively an attacker can establish control over a compromised environment.
Even that distinction may not remain useful indefinitely. Researchers observed that these more advanced use cases are gradually spreading throughout the broader threat ecosystem. As AI tools become more accessible and capable, activities once associated with a smaller group of highly skilled operators may become increasingly common.
Anthropic identified another characteristic that separated the most dangerous actors from the rest. Rather than using AI for isolated tasks, some operators built systems around AI models that connected multiple attack stages together. This allowed AI to support planning, execution, and decision-making across larger portions of an operation with limited human involvement.
Researchers describe this capability as agentic attack orchestration. In practical terms, it refers to AI systems that can assist with coordinating different phases of an intrusion, helping move an attack from one stage to another without requiring constant manual direction from an operator.
According to the report, this rising behavior exposes a limitation in existing cybersecurity frameworks. MITRE ATT&CK was designed to document attacker actions and techniques. It was not built to measure the degree of autonomy involved when AI systems help coordinate those actions.
Anthropic underlined this challenge using a cyber-espionage campaign it disrupted in November 2025. The operation involved attempts to use Claude Code in support of intrusion activity targeting organizations in multiple regions with relatively little direct human intervention.
When researchers mapped the operation to MITRE ATT&CK, it generated a profile containing 30 techniques across 13 tactics. On paper, that profile appeared comparable to many medium-risk actors included in the study. However, Anthropic's internal evaluation system assigned the operation the maximum possible risk score of 100.
Researchers argue that the discrepancy exists because current frameworks focus on what actions occur during an attack rather than how those actions are coordinated. An AI-assisted system capable of executing commands, identifying vulnerabilities, collecting credentials, and adapting to changing conditions throughout an intrusion presents a different operational challenge than a human manually performing each step.
The report notes that there are currently no ATT&CK categories specifically designed to capture autonomous orchestration, automated chaining of attack stages, or the reduction of human decision-making throughout an attack lifecycle.
Anthropic says it is actively discussing potential framework updates with MITRE to better account for AI-enabled attack behaviors. The company has also used insights from the research to strengthen safeguards within its own models, including controls intended to detect and prevent misuse involving malware development and large-scale data theft attempts.
For defenders, the findings suggest that traditional indicators may no longer provide a complete picture of cyber risk. A threat actor using AI to automate portions of an attack may achieve outcomes similar to those of a more experienced operator performing the same tasks manually. Likewise, an individual using a basic chat interface could potentially conduct operations that resemble those performed through more advanced integrations.
Google has addressed a security flaw in the Python SDK for Vertex AI after researchers demonstrated that attackers could potentially intercept machine learning model uploads and substitute them with malicious files.
The issue was identified by researchers from Palo Alto Networks' Unit 42 team, who disclosed the findings through Google's bug bounty program. According to the researchers, the vulnerability could be exploited without compromising a target organization's cloud environment, stealing credentials, or tricking users through phishing campaigns. Instead, the attack relied on weaknesses in how the SDK handled temporary storage locations during model uploads.
Researchers referred to the technique as "Pickle in the Middle." They reported no evidence that the flaw had been exploited outside of controlled testing environments. Google has since released security updates, and organizations using Vertex AI are advised to upgrade to version 1.148.0 or newer.
Predictable Storage Names Created an Opening
The vulnerability originated from the SDK's automatic staging process.
When developers uploaded a machine learning model without manually specifying a Cloud Storage bucket, the SDK generated a temporary bucket name based on information such as the Google Cloud project identifier and deployment region.
The problem was not that the bucket name could be predicted. The problem was that the SDK only checked whether the bucket existed. It did not verify whether that bucket belonged to the project performing the upload.
Because Cloud Storage bucket names are globally unique across Google Cloud, an attacker could create the expected bucket before the victim did. If that happened, model files uploaded by the victim could be redirected into infrastructure controlled by the attacker.
In practical terms, a developer could believe a model was being uploaded to their own cloud environment while the files were actually being delivered elsewhere.
Attackers Could Replace Models Before Deployment
After receiving the uploaded files, an attacker could modify or replace the model before Vertex AI retrieved it for deployment.
This becomes particularly important because many machine learning workflows rely on serialization formats such as Pickle and Joblib. These formats are commonly used to save trained models, but they also contain functionality capable of executing instructions when the file is loaded.
As a result, a manipulated model may do more than generate predictions. It can potentially run arbitrary code inside the environment responsible for serving the model.
Unit 42 researchers demonstrated that this behavior could be abused to execute attacker-controlled code inside Vertex AI's serving infrastructure.
Researchers Exploited a Narrow Timing Window
The attack required the malicious file replacement to occur very quickly.
During testing, researchers observed that Vertex AI typically retrieved uploaded files roughly 2.5 seconds after the upload process completed.
To exploit this short interval, they created an automated Cloud Function that monitored the attacker-controlled bucket and immediately replaced newly uploaded files. The replacement process took approximately 1.4 seconds, allowing the malicious model to be swapped before Vertex AI accessed it.
This timing-based attack demonstrated that the vulnerability was practical under the right conditions rather than being a purely theoretical risk.
Proof-of-Concept Reached Beyond a Single Model
After achieving code execution, researchers tested what level of access could be obtained from the serving environment.
Their proof-of-concept extracted an OAuth token from the container's metadata service and used it to interact with resources available within Google's managed infrastructure.
According to the report, the token provided visibility into additional machine learning assets, model artifacts, TensorFlow files, BigQuery metadata, access control information, system logs, Kubernetes cluster identifiers, and internal infrastructure references.
The findings suggested that a successful compromise could potentially expose information beyond the originally targeted model deployment.
Exploitation Required Specific Conditions
The vulnerability was not universally exploitable.
Researchers noted that two requirements had to be met before the attack could succeed.
First, the expected default staging bucket could not already exist in the chosen deployment region. Second, the developer needed to rely on the SDK's default bucket-generation behavior rather than specifying a storage bucket manually.
The researchers noted that newly created Vertex AI projects often satisfy the first condition because the default bucket may not yet have been created.
Google Introduced Multiple Fixes
Unit 42 reported the issue to Google on March 5, 2026.
Google's initial response introduced additional randomness into bucket names by appending a UUID value, making bucket prediction substantially more difficult.
The company later strengthened the mitigation by implementing ownership validation checks. These checks ensure that automatically selected buckets belong to the project initiating the upload, preventing bucket-squatting attacks from succeeding.
The ownership verification mechanism was included in Vertex AI SDK version 1.148.0.
At the time the researchers published their findings, neither Google's Vertex AI security advisories nor the research report listed a CVE identifier for the vulnerability.
Recommendations for Organizations
Security teams using Vertex AI should verify that all environments are running updated versions of the google-cloud-aiplatform package. This includes development notebooks, machine learning pipelines, automated build systems, testing environments, and production deployments.
Researchers also recommend explicitly defining a staging bucket owned by the organization instead of relying on SDK defaults. This reduces the risk of storage misconfigurations and provides greater visibility into where machine learning artifacts are stored during deployment.
The disclosure is the latest example of how weaknesses in supporting cloud infrastructure can affect AI systems. As organizations continue moving model development and deployment into managed cloud platforms, security reviews must extend beyond the model itself to include storage, deployment pipelines, permissions, and the services that support the AI lifecycle.