According to Arctic Wolf, the techniques vary among different affiliates, and few patterns surfaced in tradecraft via authentic Remote Management and Monitoring (RMM) tooling, hands-on-keyboard procedures and credential access.
Anubis also exploited authentic remote access and admin tools such as MeshAgent, Total Software Deployment, ScreenConnect, UltraVNC, and Zoho Assist to merge with usual IT operations while handling control of target systems.
Anubis is a RaaS gang that first surfaced in late 2024 as a spinoff of Sphinx ransomware. The ransomware campaign was first disclosed on the Ransomware and Advanced Malware Protection (RAMP) darkweb forum in February last year. As per the data from Ransomware.Live, the cybercrime gang has taken responsibility for 91 victims on its data leak website, with 11 targets in June 2026.
Some significant areas attacked are business services, technology, financial services, healthcare, and technology. Above 50% of the targets are based in the U.S, then U.K, Australia, France, and Canada.
Rubrik Zero Labs published a report in July 2025 which said Anubis promotes promising profit splits, which offers 80% of the ransom paid, and combines it with a data wiping (irresistible) feature to further blackmail the victims to pay upfront.
Experts at Rubrik said that “when Anubis's /WIPEMODE module is activated, files remain in directories but are reduced to a 0 KB size regardless of ransom payment.” The experts added that when “Anubis changes ransomware’s traditional strategic calculus, it creates powerful incentives for motivated threat actors to deploy Anubis in pursuit of lucrative returns.”
Commenting on the severity of the attack, Rubrik said that, “Knowing threat actors can revert victims' environments to this scorched-earth state with a single command significantly increases pressure on victims to pay before the wiper is fully activated.”
The ransomware incidents in 2026 consist both exploitation of CVE-2025-5777 (CVSS score: 9.3), a severe flaw affecting Citrix Net and valid VPN credential use.
The source of VPN credentials in these attacks is unknown, but experts say that they are likely to be collected after the first compromise, or via credential stuffing, initial access brokers (IABs), or information stealer operations.
A large-scale password spraying campaign targeting Microsoft 365 environments through Microsoft’s Azure Command-Line Interface (Azure CLI) generated more than 81 million authentication attempts and compromised at least 78 user accounts across 64 organizations, according to cybersecurity firm Huntress.
Huntress said the activity was observed between June 12 and June 21, with attackers typically compromising two to four accounts per day before activity surged around June 22, when 23 organizations were affected. Most of the login attempts originated from AS32167, an autonomous system associated with hosting provider LSHIY LLC.
The company said the campaign formed part of a larger wave of credential-spraying attacks spanning multiple autonomous systems and noted that the volume of such attacks across its customer base has increased more than 155-fold during the past six months. Investigators believe the operation relied primarily on previously exposed username-and-password combinations obtained from credential leak collections.
A key element of the campaign was the use of the OAuth Resource Owner Password Credentials (ROPC) flow through Azure CLI. Although ROPC has been deprecated in OAuth 2.1, it can still exchange valid usernames and passwords directly for access tokens without an interactive sign-in prompt. Huntress said this allowed attackers to authenticate successfully in environments where multi-factor authentication policies did not fully cover that authentication flow.
The investigation identified several configuration gaps among affected organizations, including MFA policies applied only to certain cloud applications or user groups, enforcement limited to non-trusted locations, and policies that had been configured but never enforced. Huntress also found that eight impacted organizations had no MFA policy enabled.
Huntress emphasized that the findings should not be interpreted as evidence that MFA is ineffective. Instead, organizations should review Conditional Access policies, eliminate deprecated authentication methods where possible, ensure MFA protections apply to all supported sign-in flows, and monitor Azure CLI authentication activity for unusual login patterns.
The IPv6 address range used in the campaign belongs to LSHIY, an internet infrastructure provider registered in Hong Kong, Wuhan, China, and New York. Huntress said it reported the activity through the provider’s abuse-reporting channel but had not received a response.
ChatGPT Atlas from OpenAI
Comet from Perplexity
Anthropic’s Claude browser
Fellou
Genspark browser
Sigma browser
LayerX experts made a proof-of-concept (PoC), which was tested against these agentic AI browser products. The findings revealed that only one browser addressed the issue after receiving the report.
An AI browser can streamline the entire workflow for the users. If you switch it to agent mode, it can click type, and visit sites that the user has already logged into. Access is the key point hare, which also becomes the problem.
Experts made a (PoC) in which an infected webpage showed a BioShock-themed puzzle that rewards wrong answers. This tricks the browser that normal rules are not applicable.
The trap works because of how these AI-powered browsers read. The webpage and instruction surface as a single stream of text, which allows a malicious page access in commands mimicking ordinary content or game rules. The agent can not tell which is which. Experts have termed this indirect prompt injection.
For instance, the compromise starts with a web page made as a puzzle. 3+4+=9 is a wrong answer but the browser rewards it. When the agent accepts that wrong answer is the reward, it follows game puzzle logic not security logic. Following this, the puzzle asks the browser to record login credentials. All six browsers could not flag it as something malicious. To win the game, the agent is commanded to go to a GitHub repository and share the data in the code, such as sensitive data like passwords.
When the link is sent to the target's GitHub repository, it retrieves SSH login credentials and sends them to the hackers. The main issue here is that browsers can’t differentiate between real scenarios and malicious fictional ones.
According to LayerX, “Once the agents figured out the rules and learned that 'incorrect' actions are acceptable, they were no longer tied to reality.” “When tasked with the final step of the puzzle – compromising user credentials – all 6 agents failed to identify it as going against their safety guardrails,” the experts continued.
The PoC did not execute any malicious commands but warned that it could do so.
According to experts, only OpenAI implemented a working patch for BioShocking in its browser.
Anthropic tried to fix the issue on its chrome login, but the patch was not working against the PoC. Perplexity did not fix the issue, and closed the report.
LayerX advises that AI vendors should add specific user acknowledgement for sensitive work, and stronger security checks.
Organizations using Argo CD to automate application deployments on Kubernetes are being urged to review their network configurations after security researchers disclosed an unpatched vulnerability that could allow attackers to execute arbitrary code on the platform's repo-server component and ultimately seize control of an entire Kubernetes cluster.
The vulnerability was identified by French cybersecurity firm Synacktiv, which says the issue affects the repo-server, a core Argo CD service responsible for retrieving application source code from Git repositories and converting it into Kubernetes manifests before workloads are deployed. Because the repo-server sits at the center of the GitOps deployment process, compromising it gives an attacker an opportunity to interfere with how applications are delivered throughout the cluster.
According to the researchers, exploitation does not require authentication. An attacker only needs network access to the repo-server's internal gRPC service, which accepts requests from other Argo CD components but does not verify the identity of the caller. Once that communication channel becomes reachable, a specially crafted request can be used to trigger remote code execution on the vulnerable service.
Synacktiv reported the vulnerability to the Argo CD maintainers in January 2025 through a responsible disclosure process. However, roughly eighteen months later, the issue remains unresolved, with no official security patch or CVE identifier assigned. The researchers chose to disclose their findings publicly to give administrators time to strengthen their deployments while awaiting a permanent fix.
At the center of the attack is Argo CD's repo-server, which continuously retrieves application definitions stored in Git repositories and prepares them for deployment by generating Kubernetes manifests. These manifests describe the desired state of applications, including containers, services, networking, storage, and other deployment configurations that Kubernetes uses to build and manage workloads. Since every deployment passes through this component, gaining control of the repo-server can provide attackers with extensive influence over the software being deployed inside a cluster.
The vulnerability stems from an unauthenticated internal gRPC interface exposed by the repo-server. gRPC is a high-performance communication framework commonly used for communication between services inside distributed applications. In Argo CD's design, the interface is intended for trusted internal communication. However, Synacktiv found that the service performs no authentication checks, allowing any system capable of reaching the port to submit requests that the repo-server will process.
The researchers demonstrated the attack against Argo CD version 2.13.3. They noted that no patched release currently exists and did not publish a complete list of affected versions, leaving administrators without a definitive inventory of vulnerable deployments.
To achieve code execution, the attack abuses Kustomize, a Kubernetes configuration management tool that Argo CD relies on to generate deployment manifests. Kustomize can also invoke Helm, another widely used package manager for Kubernetes, through the "--helm-command" option that specifies which executable should be launched.
Instead of directing Kustomize to the legitimate Helm binary, Synacktiv discovered that an attacker can send a malicious GenerateManifest request instructing it to execute a script stored inside an attacker-controlled Git repository. When Kustomize begins processing the deployment, it unknowingly launches the attacker's script in place of Helm, providing arbitrary code execution within the repo-server environment.
Although the vulnerable interface is intended to remain internal, the researchers warn that internal services should not automatically be considered secure. Kubernetes clusters frequently host dozens or even hundreds of interconnected workloads, and a compromise affecting a single pod can become the starting point for lateral movement if internal communication is not properly restricted.
Argo CD includes Kubernetes NetworkPolicy resources designed to limit access to sensitive services such as the repo-server and Redis. However, Synacktiv found that these protections are disabled by default when Argo CD is deployed using its Helm chart because the "networkPolicy.create" option is set to "false". As a result, installations that rely on the default configuration may unintentionally leave the repo-server reachable from other workloads running inside the cluster.
In such environments, compromising a single pod may be enough for an attacker to contact the repo-server and exploit the vulnerability.
The researchers also demonstrated that remote code execution represents only the beginning of the attack chain. After obtaining execution on the repo-server, they extracted the Redis password stored in an environment variable, authenticated to Argo CD's Redis instance, and modified cached deployment information. When Argo CD later performed its routine synchronization with the Git repository, the poisoned cache caused the platform to deploy an attacker-controlled workload instead of the intended application.
According to Synacktiv, this technique effectively revives a previously addressed weakness tracked as CVE-2024-31989. That earlier vulnerability, discovered by Cycode, exposed Argo CD deployments where Redis lacked password protection, allowing any pod inside the cluster to manipulate deployment cache data. Although Argo CD later introduced Redis password protection to address that issue, the cache contents themselves remain unsigned. By stealing the Redis credentials through the newly disclosed repo-server vulnerability, attackers can once again tamper with deployment data and recreate a similar compromise path.
With no software update currently available, researchers recommend treating network segmentation as the primary line of defense. Administrators should enable Kubernetes NetworkPolicy rules to ensure that only legitimate Argo CD components can communicate with the repo-server and Redis services. Organizations deploying Argo CD through Helm should verify that these policies have been explicitly enabled rather than relying on the chart's default configuration.
Administrators can inspect active network policies by running:
"kubectl get networkpolicy -A"
A properly secured deployment should display dedicated network policies protecting each Argo CD component, including both the repo-server and Redis. Missing policies may indicate that sensitive internal services remain accessible to other workloads inside the cluster.
To help organizations evaluate their exposure, Synacktiv developed a proof-of-concept tool named argo-cdown, capable of automating the complete attack chain. The researchers have postponed its public release to provide defenders with additional time to secure vulnerable environments. The tool is expected to be published on GitHub later, allowing administrators to validate the effectiveness of their own security controls.
The newly disclosed vulnerability is the latest in a series of security issues affecting Argo CD's privileged position within Kubernetes environments. In September 2025, the project patched CVE-2025-55190 after researchers found that an API token with only basic read permissions could retrieve Git repository credentials associated with a project. Several months later, in May 2026, another flaw tracked as CVE-2026-42880 enabled read-only users to access plaintext Kubernetes secrets.
Taken together, these incidents point to a recurring challenge rather than isolated implementation flaws. Argo CD occupies one of the most privileged positions within Kubernetes deployments, maintaining access to source repositories, deployment pipelines, cluster resources, and sensitive credentials. As a result, weaknesses affecting its internal services can quickly become pathways to broader infrastructure compromise.
Until an official patch becomes available, organizations should assume that internal cluster traffic cannot always be trusted. Restricting communication between workloads, enabling Kubernetes NetworkPolicy protections, and limiting access to critical Argo CD services remain the most effective measures for reducing exposure to this newly disclosed attack technique.
After an investigation of the breach, the organization discovered that between March and April, the hacker accessed files carrying personal data of employees.
It is a Japanese industrial manufacturer famous for its construction and agricultural work. Kubota has plants in 120 counties and currently employs over 52,000 people. Kubota has an annual revenue of $20 billion.
The North American division consists of facilities that make utility vehicles, tractors, and mowers.
“We discovered that files maintained by our human resources team were accessed as part of this incident. We carefully reviewed these files, and on June 16, 2026, we determined that one or more files may have contained personal information related to certain employees and their dependents,” Kubota reported on its site.
As per the announcement posted on the Kubota USA portal, the following employee information may have been revealed:
The specific data that was exposed varies per person. Kubota also started sending personalised mails to inform the individuals about the exact impact on them.
The notification information consists step by step instructions for using Kroll identity protection to help the targets address the threats coming from the leak of their personal data.
Kubota has specially advised people to look out for bank accounts and healthcare related statements and promptly report any malicious activity to the concerned authorities.
Kubot has implemented robust security measures to avoid such incidents from happening in the future.
No cybercrime gangs, data extortion gangs, or ransomware gangs have claimed responsibility for the Kubota breach.
Kubota did not report any operational or business disruptions due to the breach.
On ensuring employee safety, Kubota said, “We take the privacy and confidentiality of our employees’ information very seriously. To help prevent something like this from happening again, we have taken and will continue to take steps to further enhance our existing security measures.”