Viry a Červi

ShinyHunters claims it has dumped the personal details of millions of Charter Communications customers after the US telecom giant apparently declined to play along with the gang's latest extortion demands. According to Have I Been Pwned, the breach exposed the personal details of 4.9 million customers, including names, email addresses, phone numbers, and physical addresses. It says a smaller subset of roughly 85,000 records originating from an internal staff directory also contained job titles. Charter appeared on the ShinyHunters leak site earlier this month, with the extortion crew claiming to have stolen more than 42 million records belonging to consumer and business customers. The listing, seen by The Register, warned: "Over 42M records containing PII have been compromised. This is a final warning to reach out by 27 May 2026 before we leak along with several annoying (digital) problems that'll come your way." After the alleged deadline passed, the criminals updated the post with a familiar message for organizations that decline to pay. "Over 42M records containing PII have been compromised. The company failed to reach an agreement with us despite our incredible patience, all the chances and offers we made. They don't care." Charter, one of the largest broadband providers in the US through its Spectrum brand, confirmed it is investigating the incident but disputed the sensitivity of the data exposed. "We are aware of the situation, following our security protocols and are working with appropriate authorities," the company said in a statement provided to multiple outlets. "No sensitive personal information (PI) or customer proprietary network information (CPNI) data was exfiltrated by the threat actor as a result of recent activity." That may be technically true, but millions of names, addresses, phone numbers, and email addresses still represent a useful haul for scammers, phishers, and identity thieves. The incident is also not Charter's first brush with high-profile intrusions. The telecom provider was among the organizations reportedly caught up in China's Salt Typhoon espionage campaign last year, alongside a growing list of US telcos. The leak lands hours after Carnival Corporation, the world's largest cruise operator, admitted that ShinyHunters had also made off with the personal data of nearly six million people, suggesting the gang has been enjoying an unusually busy week. For companies weighing whether data theft is less disruptive than ransomware, ShinyHunters keeps providing fresh case studies in why that difference may not matter much to the people whose information ends up online. ®

Introduction

Containerization using Docker has become firmly established in modern development standards, significantly increasing the speed and convenience of deploying various services. Developers often use ready-made Docker images, making only minimal changes. The largest repository of container images is the Docker Hub service.

Container-hosted infrastructure is an attractive target for attackers. At a minimum, a compromised container can be used for DDoS attacks, cryptocurrency mining, or traffic proxying. The list of threats does not end there: once an attacker gains control of a container, they can steal or destroy data directly from it, access neighboring containers, or even attempt to escape the container, compromising the entire enterprise network.

At the same time, the infrastructure inside containers is typically updated less frequently and may contain outdated and vulnerable software versions. When deploying third-party images or modifying them for a specific environment, it is easy to make configuration errors that attackers can later exploit. And due to the architectural characteristics of containers, developers often face constraints when preparing images; to overcome these, they may resort to insecure solutions they find online.

In other words, containerized infrastructure can be both the simplest and the most lucrative target to exploit. Therefore, its security requires heightened attention. To minimize the risk of successful attacks on container infrastructure, it is essential to check the final Docker images, including all underlying layers, for vulnerabilities and misconfigurations. The easiest way to do this is by analyzing the Dockerfile; however, it is not always available for inspection. Moreover, it typically defines how to build layers on top of a base image from an external repository whose reliability cannot be guaranteed.

Image analysis results in Kaspersky Container Security

To help users identify insecure configurations and potential vulnerabilities within them, we have added our AI assistant to Kaspersky Container Security.KIRA (the assistant’s name) uses artificial intelligence to analyze the image and identify potential issues within, along with recommendations on how to fix them.

As part of this study, we asked KIRA to analyze a number of popular community images, and later in this article, we’ll show you the results.

Software vulnerabilities and compromise of update sources

One of the key security issues with using pre-built images is that developers do not update them in a timely manner. A Docker image is, by its very nature, a snapshot of a specific Linux distribution after packages have been installed on it. However, in most cases, it does not receive security updates on its own, unlike traditional Linux servers, where these updates are automatically installed by specialized services, such as unattended-upgrades in Debian-based distributions and dnf-automatic in RedHat-based distributions.

To apply updates to a Docker image, it must be rebuilt and redeployed. Often, this process is not automated, and some updates require additional effort to verify their correct operation, modify configurations when upgrading to new software versions, and so on. As a result, many popular images do not receive timely updates, which significantly increases the risks associated with their use.

An image that was secure at build time accumulates vulnerabilities as they are discovered in the packages installed within it, which over time significantly increases the opportunities for a successful attack on the container.

Vulnerable versions of web applications and network services accessible from the internet immediately become targets of various malicious campaigns. For example, just one day after the discovery of the CVE-2025-55182 vulnerability in React Server Components, our honeypots recorded numerous attack attempts related to this vulnerability. It was adopted by operators of many malicious campaigns, ranging from classic cryptocurrency miners to variants of Mirai and Gafgyt. Attackers are constantly adding new distribution methods and can use dozens of exploits targeting various vulnerabilities and configuration errors in popular services. Often, the same vulnerabilities are used in self-propagation mechanisms from already compromised hosts. For example, in a malicious campaign to spread the Dero miner, attackers use infected containers to automatically search for and infect new targets.

In addition to vulnerabilities that can be exploited remotely, attackers are rapidly adding local vulnerabilities to their arsenal, used to gain root privileges and escape the container: in the Kinsing malware campaign, attackers used CVE-2023-4911 (Looney Tunables) to elevate privileges, and in the perfctl campaign, the CVE-2021-4034 (PwnKit) vulnerability was used for the same purpose. The access gained was used to install a rootkit that hides the presence of perfctl on the system.

To assess the situation with unpatched vulnerabilities in containers, we took a random sample of 100 images, which included various popular solutions with 10,000 to 1 million downloads on DockerHub. In the 64 images we scanned, we found outdated software versions with critical vulnerabilities. For example, some images contained the CVE-2025-49844 vulnerability in the Redis server, leading to RCE by leveraging a vulnerability in the Lua parser; the current CVE-2026-24061 vulnerability in nginx, which in some configurations leads to a server process crash, and with ASLR disabled, again, to RCE; vulnerabilities CVE-2025-32463 in sudo and CVE-2023-4911 in glibc, allowing an attacker to gain root privileges with local access. At the same time, only one in ten Docker images from the analyzed sample is fully up to date.

TOP 10 Critical Vulnerabilities with PoC/Exploits available as shown in the Kaspersky Container Security Dashboard

It is worth noting that, of course, not every discovered vulnerability can be directly exploited by attackers. A practical risk arises when the vulnerable application or library is actually in use, and the conditions necessary for exploitation – which vary significantly from vulnerability to vulnerability – are met. Nevertheless, updates must not be ignored, as the risk of vulnerabilities being exploited – both individually and in various combinations – cannot be predicted in each specific case, and even vulnerabilities that seem harmless at first glance can ultimately pose a serious risk of compromise.

A record number of vulnerabilities in a single image

However, frequent updates have a downside. Every rebuild that downloads new packages from source repositories introduces an additional risk of a supply chain attack – a compromised dependency or a modified base image could silently inject malicious code into your environment precisely through an update. During our analysis of images from the sample, we did not find any signs of supply chain attacks. However, in March 2026, a supply chain incident occurred in the Trivy and LiteLLM projects. In the case of Trivy, the infected file was injected directly into the container image in the official repositories.

Detecting potentially malicious software using one of the images as an example

This leads to a difficult choice: infrequent updates leave known vulnerabilities unpatched within the image, while frequent updates increase the risk of supply chain compromise. Therefore, to protect your infrastructure, you need not only to regularly update base images but also to take a more comprehensive approach, specifically by pinning dependencies to known-good versions and scanning the resulting images for malware upon update.

Configuration vulnerabilities

Even a container with a fully updated image can be compromised if it is configured incorrectly. Embedding keys and secrets in the image, disabling authentication in network services, default passwords, and insecure file access permissions – all of these can be exploited by attackers in one way or another to achieve their goals.

Insecure image configurations detected by KCS based on rules

The situation is exacerbated by the fact that errors may be introduced by the authors of the original image, which complicates their detection, as this requires analyzing every layer and the command that generated it. As with vulnerabilities, not every configuration error leads to compromise: it all depends on the container’s role, its network accessibility, and many other factors. But the very use of insecure settings will sooner or later lead to errors appearing in images where their consequences will be significantly more dangerous.

Standard rules are often insufficient for analyzing problematic configurations. To gain a deeper understanding of the context and assess potential risks, AI tools can be used. Later in this section, we will examine examples of typical insecure configurations we discovered while scanning public images from Docker Hub, along with the descriptions of issues and risk mitigation methods provided by the KIRA AI assistant.

Example of container analysis using KIRA

Insecure handling of credentials Use of default passwords

In some cases, containers may use default passwords set via environment variables or directly in Dockerfile. If these passwords are not overridden, attackers will be able to access the application by using the default password.

RUN |1 DEBIAN_FRONTEND=noninteractive /bin/sh -c echo [removed]:[removed] | chpasswd

According to KIRA’s analysis, the user’s password is stored in plain text in the image layer history. Anyone who gains access to the image – whether through a public registry, a compromised build environment, or other means – will be able to extract the password. If SSH or another form of interactive access is enabled in the container, this could lead to its complete compromise and allow attackers to move laterally within the infrastructure.

Passwords may be present in environment variables. Consider the following Dockerfile snippet:

ENV SERVERNAME=localhost WWW_PATH_CONF=/etc/apache2/apache2.conf WWW_PATH_ROOT=/var/www HTTPS=on PKP_CLI_INSTALL=0 PKP_DB_HOST=db PKP_DB_NAME=pkp PKP_DB_USER=pkp PKP_DB_PASSWORD=changeMePlease PKP_WEB_CONF=/etc/apache2/conf-enabled/pkp.conf PKP_CONF=config.inc.php PKP_CMD=/usr/local/bin/pkp-start

In this example, the environment variable PKP_DB_PASSWORD is set to changeMePlease. If the user forgets to override it, the application will use the password that can be obtained from Dockerfile.

Let’s look at another image:

/bin/sh -c #(nop)  ENV MOODLE_URL=<a href="http://0.0.0.0/">http://0.0.0.0</a> MOODLE_ADMIN admin       MOODLE_ADMIN_PASSWORD [removed]      MOODLE_ADMIN_EMAIL [email protected] MOODLE_DB_HOST     MOODLE_DB_PASSWORD       MOODLE_DB_USER     MOODLE_DB_NAME    MOODLE_DB_PORT 3306

For this image, Dockerfile specifies that the administrator password is hardcoded in the ENV directive and remains in the image metadata (layer history, docker inspect). Anyone who gains access to the image (registry, build cache) will be able to extract this secret and compromise the account.

To eliminate these risks, ensure that no passwords are specified in Dockerfile. If authentication is required, you can use orchestrator mechanisms (secrets) or generate a temporary password when starting the container via the entrypoint script, without saving it in the layers. We also recommend using mechanisms for securely passing secrets at runtime (Docker secrets, Kubernetes Secrets) or, as a last resort, passing them via --secret during the build with BuildKit, but under no circumstances should they be left in the final image.

Passing passwords via command arguments

In some cases, passwords may be exposed when passed via command-line arguments, as these arguments are visible to all users on the system:

/bin/sh -c #(nop)  HEALTHCHECK &amp;{[""CMD-SHELL"" ""mysql --protocol TCP -u\""root\"" -p\""$MYSQL_ROOT_PASSWORD\"" -e \""SELECT 1;\""""] ""15s"" ""30s"" ""0s"" '\x05'}

In the example provided, the MySQL superuser password is passed into the healthcheck command in plaintext, making it visible when viewing the process list (ps aux), in audit logs, and in monitoring systems. If the attacker gains read access to the container’s processes or logs, they can extract the password and gain full control of the database.

To fix this issue, the healthcheck should use a local connection via a Unix socket with default authentication (if the auth_socket plugin is configured for root), or create a dedicated user with minimal privileges (e.g., only USAGE), without a password or with a password passed via a secure file (--defaults-file with restricted permissions). You can also use the MYSQL_PWD environment variable for healthcheck authentication, but it remains visible in /proc.

Privilege escalation in the container

One of the most common vectors for initial compromise of Linux systems is RCE in web applications and network services. Typically, these services have minimal privileges, which complicates attackers’ subsequent actions: dumping credentials, covering their tracks, attempting to escape the container, and much more.

The situation worsens significantly if the attacker gains root privileges, as this allows them to fully control all processes within the container, conceal their activity, and use methods to escape the container. For example, they can compromise the host if the container is privileged, a Docker socket is mounted inside it, or other insecure configurations and vulnerabilities exist that cannot be exploited with standard user privileges.

Similarly, this simplifies network attacks on neighboring containers, the orchestrator, and various internal services, making this configuration error a potential link in the chain for compromising the entire network.

Attacks on sudo

One of the simplest privilege escalation methods is executing arbitrary commands as root using sudo without entering a password. Consider the following example:

/bin/sh -c set -xe;     apt-get update &amp;&amp;       apt-get -y install sudo;       echo ""solr ALL=(ALL) NOPASSWD: ALL"" &gt;/etc/sudoers.d/solr;

Analyzing this configuration using KIRA immediately highlights the main issue: by installing the sudo package and setting NOPASSWD: ALL for the solr, the user severely violates the principle of least privilege. The Solr platform does not require such broad privileges to run within a container; instead, they create an easy path for escalating to root.

echo 'postgres ALL=(ALL:ALL) NOPASSWD:ALL' &gt;&gt; /etc/sudoers

In another example of an insecure configuration, NOPASSWD:ALL privileges are granted to a PostgreSQL database user, which is a direct and severe weakening of the access control policy. If an attacker gains the ability to execute code on behalf of the postgres user – through a vulnerability in a network service, an SQL injection, or by compromising of one of the processes – they will immediately and unconditionally be able to execute any commands on behalf of the root user. This is equivalent to the entire container running as root.

As a risk mitigation measure, we recommend completely removing this directive. The minimum necessary commands requiring privileges should be delegated on a case-by-case basis via sudoers with explicit specification of allowed executables and parameters, using NOPASSWD only as a last resort and for specific utilities.

Our AI assistant KIRA can identify even more complex insecure configurations, such as allowing passwordless sudo for the entire sudo group — by modifying existing rules.

perl -i -pe 's/\bALL$/NOPASSWD:ALL/g' /etc/sudoers

The risk in this example is that the command replaces standard declarations requiring authentication with passwordless execution of all commands for any user within the sudo group – potentially including postgres, should it be assigned to that group. This expands the attack surface to all group members, turning each of them into a potential point for instant privilege escalation.

To mitigate the risks, we recommend not modifying the global sudoers policy, keeping the standard password requirement, or using a more secure escalation mechanism – such as gosu to run a specific process on behalf of another user without permanent privileges.

Insecure file permissions

Another common vector for privilege escalation is insecurely configured file and directory permissions. Most often, for convenience, container image authors use 777 permissions, which allow anyone – including unprivileged users – to freely create and delete files, as well as modify their contents. This can lead to both privilege escalation and the ability for an unprivileged attacker to delete or modify logs, among other undesirable consequences.

Consider the following command:

chmod 0777 /usr/share/cargo /usr/share/cargo/bin

The risk is that directories containing binary files and scripts will become writable by any container user. This allows a low-privileged attacker to replace utilities included in cargo or add new malicious executables. When these tools are subsequently invoked, especially as the root user or via sudo, the attacker’s code will execute with the inherited privileges of the calling process, leading directly to a local privilege escalation.

To mitigate the risks, you can set the minimum necessary permissions: chmod 0755 for directories and chmod 0755/0644 for the corresponding files. The owner should be root, and only the owner should be allowed to write. Do not use chmod 777 on any system paths.

Lack of integrity checks

Downloading software without verifying its integrity can make the infrastructure vulnerable to software tampering.

For example, this risk may arise when downloading a distribution via HTTP:

RUN /bin/sh -c wget -qO- ""<a href="http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz">http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz</a>"" | tar --extract --gzip -C /opt/acestream

Using HTTP without verifying the archive’s integrity creates conditions for a man-in-the-middle attack during the image build phase. An attacker controlling the communication channel or DNS can replace the archive with malicious content, which will compromise the container and the entire environment in which it runs.

To mitigate the risks, you can configure connections to web resources to use HTTPS only — if the resource supports this protocol. You can also download the archive without extracting it, compare its checksum (SHA256) with the checksum from a trusted source, and only then extract it. It is advisable to store the verified archive in an internal artifact repository to avoid direct downloads from the network.

There will still be a MitM risk even if certificate verification is disabled:

wget --no-check-certificate<a href="https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip"> https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip</a> -O phpvirtualbox.zip

The absence of TLS certificate verification allows an attacker controlling the network segment to replace the downloaded ZIP archive with malicious content. Since the archive contains PHP code that will be executed by the web server, compromise during the build phase will result in the deployment of a backdoor or data leakage.

To mitigate the risks, remove the --no-check-certificate flag; after downloading, calculate the SHA256 hash of the archive and verify it against a known reference value (the release page or a local repository of trusted hashes). Additionally, consider using a fixed release (tag) rather than the floating 7.2-dev branch.

Conclusion

Docker containers have become a very popular means of deploying software, and attackers are by no means oblivious to this trend. They are rapidly adding software vulnerabilities and configuration errors to their arsenal and carrying out attacks on supply chains. They can compromise container infrastructure for a wide variety of purposes, from cryptocurrency mining to encrypting data for ransom or stealing information critical to the company.

Our research found that 64 out of 100 container images for popular applications contain critically vulnerable software, and only 10% are fully up to date. We also identified numerous insecure configurations, including passwords stored in plaintext in Dockerfiles and excessive privileges granted to users and processes.

To detect and prevent these threats, it is essential to strictly adhere to security measures: audit image configurations, securely manage secrets used in images, apply security updates in a timely manner, scan their contents for malware with every update, and follow industry-standard best practices for enhancing security.

This approach requires specialized solutions built to accommodate the unique characteristics of container environments. Kaspersky Container Security ensures the security of containerized applications at every stage of their lifecycle, from development to operation. The product protects an organization’s business processes, helps ensure compliance with industry standards and security regulations, and enables the implementation of secure software development practices.

Getting the location of troops at war might be as easy as buying the data from a legitimate business. America’s foreign adversaries have exploited commercial geolocation data tied to US troops, the Pentagon admits, using it to target or surveil US personnel in the Middle East. Despite that, the Defense Department hasn’t exactly moved fast to secure the information, elected officials say. Senator Ron Wyden (D-OR), Representative Pat Harrigan (R-NC), and a dozen other Congress critters sent a letter to DoD CIO Kirsten Davies on Thursday, demanding a change in smartphone security posture among US military branches. Included in the letter is what lawmakers describe as the first public confirmation that commercial location data has been used to target or surveil American troops in active war zones. The information was shared with Wyden’s office in April. The reason for the delay in publishing the information, Wyden’s team told The Register, was due to “markings that restricted public release,” which Wyden reportedly pushed back on, leading to Thursday’s letter and the attached responses [PDF] from the DoD confirming info purchased from commercial data brokers was used to target troops. “USCENTCOM [US Central Command] has received multiple threat reports concerning adversary exploitation of commercial location data to target or surveil US personnel in theater,” the DoD’s responses from April indicate. As for how exactly data brokers got access to the data that allowed adversaries to locate troops and their movements, they got it from the same sources as anyone else buying data from a commercial broker: Smartphone advertising profiles. According to the DoD responses included in Wyden’s letter, not only are US military personnel allowed to use personal devices within operational areas, there’s no actual policy that requires servicemembers to turn off geolocation capabilities on their devices when located in active war zones. “USCENTCOM's geolocation risk guidance directs personnel to disable geolocation functionality when not needed; periodically review device and application privacy settings; and limit public sharing of information,” the DoD said last month, while simultaneously admitting that such guidance doesn’t always fully disable geolocation on smartphones. In addition to personally-owned devices, the DoD’s own issued smartphones don’t disable advertising profiles, either. “The Personalized Advertising setting is disabled by group policy on the Mobile Device Management Server,” the DoD told Wyden’s team. “However, Ad Targeting Information is not disabled and can be edited by a user.” That’s not the most straightforward answer, and, when we asked Wyden’s team what it thought of the response, it agreed with our assessment that the Pentagon’s MDM disables the serving of personal ads to users, but doesn’t stop the transmission of device advertising IDs or other associated data. The DoD noted in the response that it’s in the process of migrating to a new MDM solution that allows location services to be completely disabled on government-issued devices and was targeting a completion date of early May, though it’s not clear whether the process has been finished yet. The Pentagon declined to answer any of our questions, only saying it would respond to Wyden, not us. It’s also not clear how effective that MDM migration will be, as the DoD appears to be phasing out government-issued devices in favor of a broader BYOD policy in at least one branch. According to a US Army press release from earlier this month, the branch is targeting the end of this month for the return of Army-managed work smartphones, as “the primary and preferred method for connectivity is the Bring Your Own Device, or BYOD, program.” CENTCOM has reportedly strengthened its geolocation controls in its area of operations; whether the average soldier, sailor, airman, and Marine is complying isn’t indicated. They’ve known about this for how long?! Failure to prevent the exposure of sensitive location data of military assets could be forgivable if it were a new problem, but according to Wyden’s letter, it’s not: The Pentagon likely knew about the issue for a decade. According to the letter, government contractors briefed military leadership about the ease of tracking smartphones owned by military members way back in 2016. “DoD officials have not treated this counterintelligence and force protection threat as a five-alarm fire,” the letter asserts, adding that the Pentagon “has known about this threat for over a decade, yet have failed to take meaningful steps to protect our men and women in uniform.” It’s not like there haven’t been plenty of examples of sloppy location data management compromising military operations, either. Data culled from workout tracking app Strava has been used to identify the workout routes of US military personnel jogging on base - and reveal the location of French President Emmanuel Macron thanks to his bodyguards’ sloppy security practices - and social media has also been flagged as an OPSEC disaster waiting to happen. Despite all those examples and briefings going back a decade, the problem has continued right up to the latest operations in Iran. “That foreign adversaries are still able to buy location data collected from the phones of U.S. personnel serving in military hotspots is a direct result of DoD leadership’s failure to prioritize this threat and implement commonsense cyber defenses,” the letter charges. Whether anything will be done about it remains to be seen. ®

The ongoing saga of Microsoft versus Nightmare Eclipse (aka Chaotic Eclipse), the disgruntled bug hunter with a deep understanding of Windows and an even deeper grudge against Microsoft, reached a fever pitch, with the researcher, who has thus far released six Windows zero-days, promising a “bone shattering” drop on July 14. Microsoft, for its part, finally responded to the security researcher and their weaponized Windows flaws with a blog post on (un)coordinated vulnerability disclosure about the now-public bugs: RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma, and MiniPlasma. Redmond says that none of these were reported via its official channels prior to being made public. Attackers began hammering three of the six - BlueHammer, RedSun, and UnDefend - soon after Nightmare published working proof-of-concept exploit code for each on now-banned GitHub (owned by Microsoft) and GitLab accounts. YellowKey, GreenPlasma, and MiniPlasma still don’t have fixes, and Microsoft has deemed “exploitation more likely” for YellowKey, aka CVE-2026-45585, citing a working POC. “We remain firmly opposed to these actions, and any disclosure outside proper coordination that could harm our customers and the digital ecosystem,” Microsoft wrote in a Wednesday blog, and then seemingly threatened legal action against Nightmare: “Uncoordinated disclosures that put proof-of-concept code for unpatched vulnerabilities into the hands of bad actors are never justifiable and have real-world consequences. Our security teams across the company work tirelessly tracking threat actors who look for weaknesses just like these to attack Microsoft and our customers. Our Digital Crimes Unit will continue bringing cases against these actors and those that enable their criminal activity – coordinating as needed with law enforcement around the world.” Microsoft did not respond to The Register’s questions, including whether its legal team planned to sue Nightmare, whether the zero-day researcher is a current or former employee, and whether Microsoft axed Nightmare’s MSRC account, meaning that the bug hunter can’t disclose vulnerabilities to the Windows giant. Nightmare, in their latest anti-Microsoft missive, claims Microsoft did just that. “When I actively asked you to communicate with me, you refused, humiliated me and made sure to insult me in front of people,” they wrote on Saturday. “You defame me in public with your CVE-2026-45585 advisory even though you literally deleted the Microsoft account I used to report bugs to you with and I got zero pennies from doing so and I still happily did like an idiot.” Nightmare also noted that “Microsoft still has chains in my hands,” preventing them from releasing “documents” yet, or anytime in June, and then warned: “Mark this date July 14th, I will make sure your bones are shattered that day.” Regardless of what does or does not happen on July 14, Nightmare has already caused chaos - and real enterprise-level damage, as systems engineer Muhammad Qasim Shahzad said on LinkedIn. “One person caused more enterprise-level damage in six weeks than most APT groups cause in a year,” Shahzad wrote. “The gap between disclosure and weaponization is now measured in hours, not days. Your patching window is shrinking fast.” Zero Day Initiative’s bug hunter-in-chief Dustin Childs, who previously spent about seven years working for Microsoft security and has decades of experience on both sides of the coordinated vulnerability disclosure (CVD) process, told The Register that Microsoft could have handled this better. And he wondered what happened between the two parties to get to this point. “CVD is a two-way street,” he said. “The vendor has some responsibility as well, so to go out publicly stating this person violated CVD without showing any of the correspondence seems bold.” Microsoft could also improve its communications to customers on “what the real risks from these bugs are and how they can defend themselves,” Childs added. “That clear direction seems to be missing.” Microsoft's 'dumpster fire' Luta Security founder and CEO Katie Moussouris, who pioneered Microsoft’s bug bounty program despite execs vowing never to pay researchers for bugs, said Redmond’s response to Nightmare sends “mixed messages.” “It confusingly claims their program ‘ensures researchers are compensated and publicly acknowledged’ in a statement answering a researcher who says he got neither,” Moussouris told The Register. “The language choices are also not deescalating. Microsoft invoked the outdated term ‘responsible disclosure,’ which I retired years ago at Microsoft because it was subjective and judgy.” This phrase, Moussouris added, “got in the way of coordination” when the two sides disagreed about how to best protect end users. “The mention of the Digital Crimes Unit in a post discussing vulnerability disclosure makes the post vaguely threatening, which seems intentional, but then they wrap up the post saying they welcome reports regardless of disclosure history,” she said. “No one except the parties involved can know for sure what happened between this researcher and Microsoft. Whatever the facts, it's hard to imagine why Microsoft would not try to deescalate, if for no other reason than avoiding the chilling effect on other researchers.” Security sleuth Kevin Beaumont, in his blog on the ongoing Microsoft-Nightmare Eclipse saga, called it a "dumpster fire of [Microsoft’s] own making.” Beaumont also used to work at Microsoft, and he noted that the Windows company previously hired a hacker called SandboxEscaper after she published zero-day POC exploits for Microsoft products - something that Redmond’s blog now describes as criminal. “If Microsoft’s tactic is to try to criminalise not following often arbitrary ‘responsible disclosure’ frameworks, good luck defending that in court - because there’s a whole clown car of prior decision making within Microsoft and facts which would emerge in that process,” Beaumont said. To be clear: neither Beaumont nor the researchers that The Reg spoke to support Nightmare’s zero-day antics. Childs called the “July 14” post “troubling” and Moussouris said the date plus “incendiary language … doesn't help organizations trying to make sense of the technical risk.” 'David and Goliath dynamic' Moussouris did add that this latest missive, taken in context with the earlier blog posts, “paint[s] a picture of someone who believes they have been pushed to this extreme. It is the sound of someone who believes every legitimate channel was closed to them: GitHub account deleted, payments withheld, credit stripped, then publicly accused of violating CVD after Microsoft cut off their ability to coordinate. The researcher's grievances are serious and specific.” Ultimately, “the bugs are Microsoft's,” Moussouris said. “They wrote the code and they own the risk to customers. Often researchers who previously work with a vendor respond in the extreme only when they feel there is no other choice. The power they hold is not at all proportionate to the vendor. This is a David and Goliath dynamic we don't like to see play out, especially since it’s users who lose when coordination negotiations fail." While it’s a very extreme - perhaps the most extreme - example of coordinated disclosure gone wrong, it’s not an isolated problem. Researchers have been complaining about CVD, and specifically Redmond’s bug disclosure habits, for years. “While some companies have improved, Microsoft has not,” Childs said. “If anything, they are seen as difficult to work with, especially if your bug is Moderate instead of Critical. I’ve had researchers tell me that they stopped looking at Microsoft altogether because they were too difficult to work with.” Plus, these types of disagreements between researchers and bug bounty programs will likely increase, as AI-assisted bug reports become the norm and vulnerabilities skyrocket. “We as an industry need to take a breath, remember there are real people involved, and that poor interactions could lead to real customer risk,” Childs said. “Real-world impact is lost far too often when disclosure goes wrong.” ®

It's 8 pm. Do you know where your agents are? Snowflake plans to buy Natoma, a startup that has made a gateway for managing AI agent permissions across enterprise applications, so users can focus on getting work done without wondering if their agents have violated security policies. During Snowflake's first-quarter fiscal 2027 earnings call, company CEO Sridhar Ramaswamy said Natoma is a critical piece of the company's broader strategy around what he called the "agentic control plane," where AI agents can take actions across business systems while still operating within the organization’s security controls. "With Natoma, users can do things like send emails, summarize Slack conversations, check calendars, and open Jira tickets without ever leaving Snowflake Intelligence or Coco," Ramaswamy said during the call, referring to two of Snowflake's AI products. “The important point is not just convenience. It is control. These actions happen from a governed environment with enterprise security, permissions, observability, and policy enforcement built in.” Natoma’s software acts as a gateway for Model Context Protocol (MCP) servers, connectors that allow AI agents to interact with external software tools. The platform enforces identity verification, access policies, and audit controls at the level of individual tool calls, tracking who requested an action, what permissions they hold, and whether the system should allow the action to proceed. “The reason MCP and Natoma are a big deal is they now bring the entirety of SaaS application context into these products, and so I've done deep research reports, for example, that can now look for information from Snowflake, from the web, from Google Docs, also from Slack, and synthesize that into something that is astoundingly meaningful,” Ramaswamy said. “And these also let you take action instantly. You can flag somebody, you can compose emails and send it, and you can take actions on the underlying applications, and that's the promise.” In a blog post, Natoma's four founders — Pratyus Patnaik, Will Potter, Zachary Hart, and Paresh Bhaya — said Natoma brings the secure connectivity, identity, and governance layer that helps Snowflake experiences extend safely into the applications their teams already use. "We started Natoma in 2024 with a simple belief: AI agents would fundamentally change how work gets done inside enterprises, but they would only reach production if organizations could trust and control how those agents access data, use tools, and take action," they wrote. "Snowflake sees the same future we’ve been building for at Natoma: enterprises need a trusted control plane for the agentic era. They need AI grounded in their own data, governed by their own policies, and connected to the full complexity of their technology stacks." Financial terms of the acquisition were not announced. If it passes customary regulatory and closing conditions, the deal would bring 20 employees to Snowflake. This is Snowflake's sixth acquisition announcement since June 2025, when it said it would buy PostgreSQL provider Crunchy Data for what a source told CNBC was $250 million. In November 2025, Snowflake announced that it would buy database migration outfit Datometry and data discovery platform Select Star. No sale price was provided for either transaction. In January, Snowflake said that it would buy Observe, an AI-powered observability platform, for $1 billion. The next month, Snowflake said that it planned to buy TensorStax, an AI-powered data pipeline planner. The Natoma deal was announced the same day that Snowflake signed a five-year, $6 billion agreement with AWS centered on Graviton-powered compute and AI infrastructure for its growing agentic AI ambitions. During the earnings call, Ramaswamy said that the acquisition pushes Snowflake's agentic control plane beyond data and development workflows into everyday applications where work actually happens. He said that Natoma's integration would allow Snowflake's Cortex Code, also known as “Coco,” and Snowflake Intelligence products to become a single interface for daily tasks including querying enterprise data, updating CRM records, searching across file storage, and managing communications. "These actions happen from a governed environment with enterprise security, permissions, observability, and policy enforcement built in," Ramaswamy said. Mayank Upadhyay, chief security and trust officer and VP of engineering at Snowflake, wrote in a blog post announcing the Natoma deal that the tool summarizes his unread emails, searches across Slack and Google Drive when he cannot remember where something was shared, and surfaces what he needs without switching between applications. He described the Natoma acquisition as a continuation of work Snowflake started earlier in the year with AI guardrails and prompt injection protection, building toward what he said was a portfolio for a more secure enterprise AI.®

Windows Server 2016 might be long in the tooth but that isn't about to stop Microsoft breaking stuff. The May 12 security update introduced another bug for administrators to worry about. According to Microsoft, if the server hostname is exactly 15 characters long (like, for example, THEY-NEVER-TEST), domain controller discovery might fail. In the notes for the glitch, Microsoft wrote: "When the hostname is 15 characters long, DCLocator calls (for example, using nltest /dsgetdc: /pdc) will return ERROR_INVALID_PARAMETER, preventing applications and administrative tools from locating a domain controller." In other words, anything that depends on a domain controller lookup might stop working. As an example, Microsoft gave Distributed File System (DFS) Namespace management, which would certainly be inconvenient. DFS Namespaces is a Windows Server role that allows admins to group shared folders across different servers into a single namespace. A single path can lead to files located on multiple servers. Unless, of course, the domain controller lookup is broken. Microsoft lists no workaround for affected users, though changing the server hostname to something other than 15 characters would presumably avoid the trigger. "The issue is under investigation, and additional information will be shared as soon as it becomes available," it said. Microsoft still officially supports Windows Server 2016. Mainstream support ended in 2022, but extended support will continue until January 12, 2027. Microsoft is offering up to three more years of support via the Extended Security Updates (ESU) program after that. Earlier this year, Esben Dochy of Lansweeper told The Register that the operating system accounted for just 2.2 percent of all Windows devices it tracks, but 20.3 percent of all servers. That figure is unlikely to have dropped dramatically in the months since, so there is a fair chance that an administrator with a 15-character hostname could be affected. In addition to the Windows Server 2016 problems, the May 2026 security update has failed during installation on some Windows 11 devices when the EFI System Partition is insufficient in size. It is reassuring to know Microsoft's talent for breakage shows no bias toward any particular vintage. ®

Carnival Corporation - the world's largest cruise operator - has confirmed a digital heist, a month after hacking crew ShinyHunters claimed to have stolen millions of customers' records. The breach, Carnival confirmed, stemmed from an April 14 social engineering attack on an employee, though the company declined to comment on the scale or name ShinyHunters. However, a company filing with the Maine attorney general's office puts the number of affected individuals at just under six million, down from the 8.7 million records previously listed by Have I Been Pwned. Carnival previously acknowledged the phishing attack at the time, but it did not say whether any data had been accessed or stolen. ShinyHunters claimed it lifted terabytes' worth of Carnival records and hinted at a breakdown in negotiations, likely related to the criminal outfit's extortion demands. "The company failed to reach an agreement with us despite our incredible patience," ShinyHunters wrote on its data leak site, adding: "They don't care." Following a "thorough and time-consuming analysis of the impacted data," Carnival confirmed that names, addresses, email addresses, phone numbers, dates of birth, and state identification numbers were all included in the breach. As is often the case in data theft incidents, individuals will be affected to different degrees, depending on what information they shared with the company. Carnival began sending notifications directly to affected individuals on Wednesday. Those communications include details about how recipients can redeem two years of free credit monitoring services, as is common in US breach notifications, via TransUnion. It closed its message with a promise to improve: "In addition to the comprehensive security measures the company had in place prior to the incident, it has taken steps to further safeguard its systems, including enhancing its security and monitoring controls. "The company will continue to advance its IT security and data privacy controls to stay ahead of an ever-evolving threat landscape." ®

PWNED Welcome, once again, to PWNED, the weekly column where we cover high-security hijinks that are at least partially the victim’s fault. This week, we have a trio of tales that involve incredibly unprofessional behavior, inappropriate use of corporate resources, and outright theft, all dealt with by IT. Have a story about someone leaving a gaping hole in their network? Share it with us at [email protected]. Anonymity is available upon request. Our trilogy of tech exposure comes courtesy of Zach Lewis, the current CIO and CISO at the University of Health Sciences and Pharmacy in St. Louis. Before his current role, Lewis worked for various other companies in IT roles and he has some tea to spill. At one job, Lewis was working as a sysadmin when the CEO asked for help recovering photos he had accidentally deleted from a company file share. The files were accessible to anyone at the organization, and Lewis searched archived copies in Google Picasa to restore them. Unfortunately, the pictures the CEO was missing included many that were very much NSFW. “So I was called in to sit down with him and look at it. And we're just like I restore everything. We start clicking images to make sure everything's there, just doing a random subset check,” Lewis said. “And, uh, just some pornography comes up and he's sitting right next to me. I mean, right next to me, he's just like, oh yeah, that's just some of my porn.” When he was done restoring the photos, Lewis left the room. It was clear the boss had no shame and no problem with IT seeing his explicit images or with storing them where any employee could download them. They were even mixed in with official photos and family pictures. However, knowing this was bad policy and could probably lead to a lawsuit, Lewis approached human resources and told them about the problem. The HR representative instructed him to delete all the smut from the network, even though it belonged to the big boss. He did that, and fortunately, did not face any repercussions at work for deleting the big man’s cheeky pictures. He wore a top hat In another instance, Lewis was asked to look at a coworker’s computer when the employee thought he had gotten a virus on his laptop. However, the colleague cautioned IT not to look through his files. After a little while, Lewis noticed a folder filled with other subfolders that were festooned with adult images, both of naked women and of the employee himself without clothes on. All of the photos had appropriately descriptive file names too. Perhaps most embarrassing of all for the coworker is that Lewis saw his semi-naked pictures. To be fair, he was dressed in the images, as he was wearing a top hat – but nothing else. The problem, Lewis notes, is that employees treat their work computers as if they are home computers and do not think about the implications of having personal images on something that belongs to a corporation. He suggests setting a firm policy against this kind of thing and educating workers about the policy. When workers inevitably violate the policy, it’s time for a gentle reminder. “A policy is just, you know, paper, right? It's hard to enforce that,” Lewis said. “You can talk to the user in this instance. In this most recent instance with this guy in the top hat, it was ‘hey, these are company resources’ when I gave the computer back to him.” Kids’ YouTube upload exposed a potential thief In another gig, Lewis worked at a university. When one athletics coach quit, he was supposed to leave his school-issued iPad on his desk. But when the IT department came to collect the equipment, this tablet was missing. No one could find the missing iPad, but a month later, someone uploaded a new video to the school’s YouTube channel. The video featured a different coach's kids and appeared to have been uploaded from his house. Apparently, the other coach had allegedly snatched the iPad off of the first coach’s desk and given it to his kids. The kids then used the iPad to film a funny home video and upload it to YouTube, not realizing that it was connected to the school’s official YouTube account. Lewis notified HR, who called the apparent thief in. At first, he denied that the children in the video were his offspring. However, the HR agent then showed him a photo of him and his kids on social media together and he admitted, okay, he was their dad. The coach then said he didn’t know how the iPad got into his house. But he grabbed it and returned it to IT. There are a lot of problems with the iPad situation from a security perspective. First, the iPad that wasn’t turned over clearly was not locked to the point where someone else couldn’t get into it. It had access to the school’s YouTube account, so any thief could add their own content to it and it may have even had PII (personally identifiable information) about some student athletes. Bottom line: make sure departing employees hand over equipment directly to IT. Don’t let them just leave equipment on a desk. And make sure even tablets require biometric access. ®

Introduction

In late April 2026, a client reached out to us for incident response support after discovering a miner running on users’ computers. We later discovered that the malware was being distributed via illegal movie and TV show streaming sites. The infection chain leveraged a fake update for a video player plugin. When the user attempted to watch a video, the player displayed a message saying the plugin version was outdated and asking to install an update to continue.

Clicking the link downloaded a ZIP archive with the following contents:

The archive contained a legitimate executable, HLS Installer.874.exe, alongside a malicious DLL. Launching the EXE triggered a DLL side-loading mechanism, injecting the malicious module into a legitimate program process and executing code within its context. The library contained the logic for deploying the miner and establishing persistence on the device.

At the time of the investigation, the infection risk was associated with two pirated video sites in the .ru and .top TLDs.

Link to previous campaigns

The current incident does not appear to be an isolated case. After analyzing the infection vector and the logic of the DLL, we concluded that this activity is a continuation of a campaign involving pirated digital libraries, which was previously described by another cybersecurity company.

The delivery mechanism for the malicious archive has remained virtually unchanged. Previously, the archive was downloaded in parts from the domain file[.]ipfs[.]us[.]69[.]mu, but this domain was unavailable at the time of our investigation. Instead, the threat actor employed a new website, urush1bar4[.]online.

The structure of the archive has also been preserved: inside is a legitimate executable and a large malicious DLL (see the screenshot below).

In the course of our research, we also discovered a blog post by NTT Security describing a similar delivery method for a malicious archive. In that instance, the threat actors displayed a fake browser crash page (shown below) while simultaneously downloading an archive to the device with a name starting with chromium-patch-nightly.

This scenario resembles the current scheme involving the fake video player plugin update. Given the previously described activity, it’s safe to assume that this campaign has been active since at least 2022. Throughout this entire period, the threat actor has been updating both the downloadable malware and individual parts of the infection mechanism.

Potential distribution scale

As in previous episodes of the campaign, infections occur via highly popular websites. As of late April 2026, sites linked to the campaign typically displayed extremely high monthly traffic. For instance, the audience for the smallest of the free digital libraries stood at 11,000 users, while the largest reached 4.7 million. For pirated movie and TV show streaming sites, this figure ranged from 2.1 million to 27.4 million. In April, the total number of visits to websites where the malware described in this study was detected reached 40 million.

The popularity of these sites increases the potential scale of the miner’s distribution. Furthermore, the campaign is not limited to a single type of platform: the malicious archive is being distributed through both online digital libraries and movie and TV show streaming sites. This broadens the potential range of victims and makes it more difficult to attribute the threat to a single infection vector.

The downloadable archive

The current version of the downloadable malware is a ZIP archive containing a legitimate EXE file and a malicious DLL. When the executable runs, the library side-loads into its process, triggering the malicious logic.

The technical analysis that follows covers the current version of this malware. This version was first observed in April 2025 and has been distributed unmodified for over a year.

DLL analysis

Most of the data inside the DLL carries no meaningful weight and was randomly generated just to inflate the file size and impede analysis.

Amidst the large volume of junk code inside the DLL, there is a single function that triggers a stack overflow during execution:

Based on the code, the size of the stackBuf buffer on the stack is only 64 bytes, and the SmashStack function overwrites this buffer without validating the length of the input data.

This overflow constructs a ROP chain that decrypts the next stage. After decryption, it transfers execution to code located within the modified DOS header of the PE file:

The header was intentionally modified to make it into valid shellcode:

pop r10 push r10 call $+5 pop rcx sub rcx, 9 mov rax, rcx add rax, 5C1000h call rax retn

This shellcode passes control to a function located at offset 0x5C1000 from the base of the PE file. This function then reflectively loads the same PE file into memory.

Going forward, we will refer to this decrypted PE file as the main module.

Main module

The module’s behavior across its different operational stages is detailed below:

The main module is a modified fork of the SilentCryptoMiner project. We have previously analyzed miners leveraging this project in other posts: Scam Information and Event Management and Undercover miner: how YouTubers get pressed into distributing SilentCryptoMiner as a restriction bypass tool. However, this specific fork has not been documented anywhere before, which is why we decided to break down its unique features in detail in this article.

Upon an initial run, the main module checks whether it has permission to proceed with execution. To do this, it collects the following data from the victim’s device:

• Processor information
• The serial number of the C:/ drive
• Whether the process was launched with elevated privileges
• The process start time in Unix timestamp format

The information is transmitted as a single large DNS query using the DNS tunneling technique. An example of the DNS query is shown below:

The attackers disguise the DNS query as legitimate traffic through low-level packet crafting and by using a domain name ending in microsoft.com. However, the IP address to which the query is actually sent has no relation to Microsoft.

DNS query crafting code

The execution of the main module proceeds only if the following byte sequence is detected in the response: 01 02 03 04. Following a successful check, the main module launches, and the subsequent logic is adjusted depending on whether the process has elevated privileges on the compromised host.
Let’s look at both scenarios:

1. The process is launched with elevated privileges.

In this case, preparatory steps precede the miner launch:

• The malware adds Windows Defender exclusions for EXE and DLL files, as well as for the %USERPROFILE%, %PROGRAMDATA%, and %WINDIR% folders.
• It kills Microsoft’s Malicious Software Removal Tool (MSRT) by calling ZwSetInformationFile with the FileDispositionInformation type, which causes the mrt.exe file to be deleted upon closing. To prevent MSRT from being automatically installed during the next update, the DontOfferThroughWUAU parameter is created with a value of 1 under the HKLM\Software\Policies\Microsoft\MRT registry key.
• Automatic hibernation and sleep mode are disabled for when the device is running on both AC power and battery.

powercfg /x -hibernate-timeout-ac 0 powercfg /x -hibernate-timeout-dc 0 powercfg /x -standby-timeout-ac 0 powercfg /x -standby-timeout-dc 0

This is done to maximize the miner’s potential runtime on the device.

Next, to achieve persistence, a copy is created in the C:\ProgramData\Google\Chrome directory, after which the GoogleUpdateTaskMachineQC service is registered and configured to launch automatically at system startup.

Finally, four reflexive loads are executed: the components are injected directly into the memory of the target processes without writing to disk, having bypassed standard Windows loading mechanisms. Each implant is injected into its own host process:

• RAT agent → into conhost.exe
• Watchdog → into explorer.exe
• CPU miner → into explorer.exe
• GPU miner → into explorer.exe, but only if a discrete GPU is present in the system. This is verified by enumerating all display adapters in the system.

2. The process is launched with standard privileges.

In this scenario, the miner begins repeatedly triggering User Account Control (UAC) prompts until it is successfully executed with elevated privileges. The workflow is as follows:

1. Upon initial execution, a copy is made to the %USERPROFILE%\AppData\Roaming\Sandboxie directory and relaunched from there. Simultaneously, an attempt is made to launch it with elevated privileges via UAC.
2. If execution occurs from the Sandboxie folder:

• Persistence is configured for the miner copy in this folder by adding an entry to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run.
• Every three minutes, an attempt is made to launch with elevated privileges via UAC until the GoogleUpdateTaskMachineQC service is successfully installed.

A successful installation requires all of the following conditions to be met:

1. The GoogleUpdateTaskMachineQC service exists in the system.
2. The Start value for this service is set to 2 (Automatic).
3. The ImagePath value points to a file in the C:\ProgramData\Google\Chrome folder.
4. This file exists on disk.

Watchdog

The purpose of this component is to ensure the uninterrupted operation of the miner. At the very beginning of its execution, it copies all files from the C:\ProgramData\Google\Chrome folder and encrypts the contents of each file using a cyclic XOR algorithm with the key AFeIboiOmImJS2ypJU0pTpAO61SELkUc. After that, the encrypted contents are written into the process memory, and the following structure is created in memory for each file:

class FileContainer{ wchar_t* fullPath; // full path to file size_t* ptrSize; // pointer to file size uint8_t* xorEncryptedFile; //pointer to buffer containing encrypted file contents };

As soon as the contents of all files are saved in memory, Watchdog enters an infinite loop, where every five seconds, it checks the integrity of the installed GoogleUpdateTaskMachineQC service, just as the main module does. If the service is found to be incorrectly installed, the miner overwrites its files in the C:\ProgramData\Google\Chrome path with the contents acquired at startup.

To successfully remediate the miner, this module, which runs inside the explorer.exe process, must be terminated first.

RAT agent

This module provides remote control capabilities via four commands, which are described at the end of this section. The command-and-control addresses used to receive these commands follow this format:

• http://{domain}.space/index.php?authorization=1
• http://{domain}.site/index.php? backup version

The {domain} is calculated based on the current date. The process starts with the current year, then adds the zone identifier for the current month. All 12 months are divided into four zones. Finally, the word microsoft is appended to the resulting string. This final string is used as the input for subsequent double hashing using the MurmurHash64 algorithm. The hash output is the domain for the implant to communicate with.

At the time of writing this, the following domains were registered:

• 2025, April-July → 5d14vnfb[.]space
• 2025, August-November → r7mvjl67[.]space
• 2025, December → zgj1tam9[.]space
• 2026, January-March → jeaw520i[.]space
• 2026, April–July → qdmagva5[.]space

An example of a request to the C2 server is provided below:

As can be seen, the request contains an encrypted body consisting of data encrypted via AES-CBC with the key 0123456789abcdef0123456789abcdef and the initialization vector 000102030405060708090a0b0c0d0e0f. The data contains a list of installed programs on the system, along with processor information and the serial number of the C: drive.

This information is likely used by the backend to check for virtual or debugging environments.

The first 16 bytes of the server response body represent the initialization vector for the AES-CBC algorithm with the key 0123456789abcdef0123456789abcdef, while the remaining bytes are the data encrypted with this algorithm. The decrypted data contains a malicious payload, as well as its RSA-SHA256 signature (sign):

struct PLAINTEXT{ uint32_t len_payload; uint8_t payload[len_payload]; uint32_t len_sign; uint8_t sign[len_signature]; }

The authenticity of the message is verified via the sign signature using the server’s public key, which is embedded in the executable.

Inside the malicious payload is a 4-byte code that determines the subsequent behavior of the program, along with additional data whose meaning depends on the code.

The table below lists the four remote control commands for the RAT agent module.

Code Purpose 1 Execution of an arbitrary command 2 Reflexive execution of the provided PE file within the explorer.exe process 3 Execution of the provided shellcode 4 Exit The miners

Depending on whether a discrete GPU is present in the system, either the CPU miner alone or a combination of the CPU and GPU miners is launched. The CPU miner is based on XMRig, while the GPU miner supports multiple algorithms.

Upon initial execution, both miners attempt to retrieve their startup configuration from a remote server. The potential addresses are listed below:

• “{domain}.strangled.net”
• “{domain}.ignorelist.com”
• “{domain}.ftp.sh”
• “{domain}.zanity.net”

As with the RAT agent component, the server address is generated from the current date — in this case, the server address changes every week. This results in quite a large number of domains for the 2020–2030 period; however, all of them point to the same IP address: 107[.]172[.]212[.]235. The first available domain out of the four potential domains listed above will be used.

The algorithm for retrieving the configuration from the server is completely identical to that used by the RAT agent, with the sole exception that th1s1sth3key0f4n1ntere5t1ngw0rld is used as the AES-CBC key in this scenario, and the configuration resides within the payload. The retrieved configuration is encrypted via AES-CBC using the key UXUUXUUXUUCommandULineUUXUUXUUXU and the initialization vector UUCommandULineUU. The encrypted data is then converted into a base64 string, which is passed as a command-line parameter to launch the miner inside the explorer.exe process through process hollowing.

Conclusion

Our investigation focused on an ongoing campaign distributing miners via popular illegal content sites. The threat actors leverage a variety of sites, ranging from online libraries to movie and TV show streaming platforms. There is no telling what channels they will use to distribute the malicious archive in the future. However, the current case shows that users visiting pirated websites continue to take a serious risk.

Our products detect this malware with the following Generic verdicts:

• HEUR:Trojan.Win64.DllHijack.gen
• MEM:Trojan.Win32.SEPEH.gen

Indicators of Compromise

Malicious archive download URL
urush1bar4[.]online

Malicious DLL libraries:
6A0FE6065D76715FEEBC1526D456DB73
7F624407AE489324E96A708A09C17E6F
02A43B3423367B9DDDC24CC7DFC070DF

RAT C&C:
5d14vnfb[.]space
r7mvjl67[.]space
zgj1tam9[.]space
jeaw520i[.]space
qdmagva5[.]space

Configuration retrieval address
107[.]172[.]212[.]235

UnamWebPanel control panel addresses
m4yuri[.]online
kristina[.]quest

CrowdStrike, working with Google and the Shadowserver Foundation, said it has taken down the Glassworm botnet, a self-propagating, credential-stealing worm that has targeted developers and spread through poisoned software packages since early 2025. The endpoint security giant’s Counter Adversary Operations team and partners hit all four Glassworm command-and-control channels simultaneously at 1400 UTC on Tuesday, “severing the operators from their infected machines and their ability to deliver new malicious payloads,” according to CrowdStrike’s blog. Google Threat Intelligence Group chief analyst John Hultquist confirmed his company’s involvement in a social media post. “As part of our disruption efforts, we are working with partners to bring more pain to attackers, especially when we see them abusing our products or targeting our users,” Hultquist wrote. A spokesperson declined to provide additional details to The Register about Google’s role in the takedown. The disruption comes as another self-replicating worm, Mini Shai-Hulud, rips through open source code and miscreants poison GitHub repositories and npm packages in similar supply-chain attacks also targeting developers’ environments. “Glassworm marked a significant shift in the threat landscape that should serve as a wake-up call for every organization that ships or consumes software,” CrowdStrike wrote. “Adversaries are no longer just targeting products, they're targeting the developers who build them.” First spotted by endpoint security shop Koi in October 2025, Glassworm used invisible Unicode-based code injection, blockchain-based C2 infrastructure, and Google Calendar as a backup command server to turn infected developers’ machines into criminal proxy nodes. This self-replicating worm initially targeted VS Code extensions on the OpenVSX marketplace before moving on to npm and Python packages, and later poisoned more than 300 GitHub repos using stolen credentials harvested in earlier Glassworm infections. This worm appeared about a month after another self-propagating malware strain, Shai Hulud, first wormed through npm packages including those maintained by CrowdStrike. Glassworm infected all platforms - including Windows, macOS, and Linux systems - stealing credentials and other sensitive information, and also spawning its own Node.js remote access tool called GlasswormRAT. C2 architecture designed to withstand takedowns Glassworm’s C2 infrastructure used four distinct channels to complicate takedown efforts. These included the Solana blockchain, with C2 server addresses encoded in the memo fields of blockchain transactions, ensuring the C2 couldn’t be taken offline through conventional means. It also used Google Calendar event titles as dead-drop locations for Base64-encoded C2 paths. The GlasswormRAT used a decentralized BitTorrent Distributed Hash Table (DHT) for configuration data stored against hardcoded public keys. And finally, Glassworm relied on traditional C2 servers, hosted on commercial VPS providers, as the final payload delivery mechanism. Disrupting all four channels “required precision and timing,” according to CrowdStrike. “Taking down only one channel would have left the others operational, allowing the operators to quickly reconstitute.” All Glassworm-infected machines now beacon to the benign CrowdStrike-operated IP address 164.92.88[.]210. The security shop urges organizations to review network logs and endpoint telemetry for connections to this address, which indicate a Glassworm infection. ®

More than half of businesses had an AI-related security incident or a scare in the past year — even as executives remain overwhelmingly confident in their ability to manage the risks of employees using AI tools, according to a study commissioned by identity and access management leader Okta. “For the purposes of this survey, an AI security issue is defined as an actual incident, i.e. a breach, data exposure, or system disruption, or a close call, meaning an issue was identified before it caused harm to the organization,” Harish Peri, SVP and GM for AI Security at Okta, told The Register. Of those respondents who reported a security problem, 26.7 percent described an actual incident — a breach, data exposure, or system disruption — while 31.2 percent identified a close call caught before it caused harm. Yet, overall, 58 percent of executives reported that their organization experienced an AI-related security problem in the past 12 months and the data is pointing to “shadow AI” use by employees as the culprit, Peri said. “The old adage in cybersecurity is that you can’t protect what you can’t see. Our research shows that 52 percent of knowledge workers admit to using unapproved AI tools,” Peri told us. “Security and compliance teams can’t govern the usage of AI tools they don’t know are being used. Organizations must implement an effective AI governance framework that prioritizes identity-centric controls, automated discovery, and secure sandboxes to test drive AI tools safely.” The AI Agents at Work 2026 report was commissioned by Okta and conducted by Apprize360 in March. It surveyed 292 executives and 492 knowledge workers across seven countries: the US, UK, Australia, Canada, Japan, France, and Germany. It also showed a disconnect between how leaders believe AI is being used within their organizations and what employees actually do. Whether it's coding assistants, browser extensions, or industry-specific utilities, the study said what unites all of the tools is their need for data and, in many cases, access to an organization’s internal systems. Peri said the survey found risky employee behavior when it came to interacting with AI models. Knowledge workers actively used unapproved AI tools, shared confidential company documents with those tools, handed over HR information to AI, and in 16 percent of cases, provided their login credentials. "These risky behaviors — whether intentional or not — increase the attack surface across an organization," Peri told The Register. Despite that, 90 percent of executives had confidence in their organization's visibility into AI tools, even as more than half of knowledge workers admitted to using AI tools without approval, with 24 percent adding that they do so regularly. Apart from the security issues, the survey found that AI agents and AI tools are gaining widespread adoption. Ninety-two percent of executives surveyed said autonomous AI agents are already in widespread or moderate use across their organizations, while nearly two-thirds of knowledge workers reported using an AI tool at least daily. Among those workers, 68 percent used AI agents, while 62 percent regularly used LLMs and AI-infused chatbots. The results of the survey vary by geography, too. The United States led all surveyed countries, with 67 percent - more than two-thirds - of workers reporting they use unsanctioned AI tools. Australia came in second, with 60 percent of workers saying they engaged in unapproved AI usage. In the United Kingdom, some 55 percent of workers ignore the rules, while roughly 50 percent of Canadian workers reported using unauthorized AI tools. Workers in France and Germany reported the lowest rates of unauthorized AI usage with each at around 30 percent. The gap between executive confidence and employee reality is widest in the UK, where 96 percent of executives expressed confidence in their AI visibility, while more than half of workers used unapproved tools. Peri said there’s no easy fix. “For most organizations, shadow AI emerges unintentionally and isn’t intended to be malicious,” he told The Register. “Shadow AI primarily causes headaches for leaders because they don’t have the proper visibility, governance, and security controls for tools the organization isn’t managing.” Okta’s survey recommends that organizations should assume shadow AI exists and make discovery a priority. They should make the secure use of AI the easiest path, and define an AI governance strategy now. Peri said strict AI bans may actually make the problem worse by pushing more usage underground. A more effective approach, he said, involves talking with employees to understand what they need and making approved tools easier to use than unsanctioned alternatives. ®

The FBI is warning unsuspecting lawyers that their firms continue to be an active target for members of a longstanding extortion crew. Silent Ransom Group has been operating since 2022, by the FBI’s reckoning, and its latest message [PDF] about the gang comes almost exactly a year after its last. The group is still targeting US law firms and their staff, and the criminals are pretending to be company IT staff. It also warned last year that the callback phishing specialists had started physically walking into the law firms’ offices when remote social engineering attempts go south. The FBI’s latest advisory reaffirms these findings, with fresh attacks reported in Spring 2026. Law firms should be locking up their USB ports because the extortion crew is still sending members to plug in their thumb drives into the computers, for when they can’t convince employees to surrender remote access. In these scenarios, they rock up to the victim they’ve tried to phish and socially engineer from behind a phone or computer screen, continue the facade of being a company IT rep, and then claim they need to image the person's device or create a backup file to assess the damage of their own phishing email. What they’re actually doing is copying important files onto said thumb drive, which SRG will later use to extort the law firm. The FBI didn’t say exactly how many of these in-person callouts SRG has made, but it was evidently enough to include in a fresh advisory on the group’s methods and tactics. According to the advisory, these attacks were first reported in Spring 2026. SRG in brief SRG’s target industries used to be broader than just legal. The hack-and-leak group has been known to target organizations operating in various industries, but the legal sector has remained a common theme since 2023. The FBI said in its advisory on the group last year that it believes SRG consistently targets US law firms “likely due to the highly sensitive nature of legal industry data.” When they’re not sending crooks into office blocks, SRG’s primary goal is to achieve their aims through callback phishing. Using SMS messages or emails, group members would single out employees at target companies, asking them to call a number while impersonating real IT staff. If the staffer fell for the scheme, they’d call up, and the SRG IT imposter would attempt to convince them to grant access to a remote desktop session, during which they would elevate their privileges and set about stealing data to use as extortion leverage. In some cases, SRG will run WinSCP or a disguised version of Rclone to scoop up files of interest. In others, they are known to share those documents using internal file-sharing platforms such as Google Drive or Microsoft OneDrive. Before the callback phishing methodology, the group would send emails claiming that a fake subscription had been authorized that would charge small sums to the target’s account each month. The email included a phone number to call in order to cancel the subscription, and once on the call, the crooks would convince the target to install remote access software, and rinse-repeat the data theft playbook. SRG is not known for using ransomware, but it operates a data leak site (DLS) just like any other extortion crew and charges victims to return the data they stole, threatening to leak it online if they refuse to pay. Recent alleged victims of the group have included law giant Jones Day, the legal eagles favored by US president Donald Trump during both his election campaigns. SRG listed Jones Day on its DLS, and the law firm confirmed a “cyber phishing incident” in April, but did not name SRG as the culprits. Your country needs you The FBI pleaded with the public to send it any evidence of SRG in action to aid future investigations. Of particular use would be phone numbers used to contact the crooks, copies of the phone call transcripts and phishing emails, cryptocurrency wallet information, and identifying information of the individuals who step foot in office buildings. As for how to prevent attacks from SRG or others adopting similar methods, the FBI recommended that organizations disallow connecting external drives to company-issued devices, especially those that store confidential or otherwise sensitive information. Verifying the credentials of each person walking into the building wouldn’t hurt, either. The usual advice applies for the group’s remote attacks: limiting access to sensitive data from less-secure networks and requiring phishing-resistant MFA for as many services as possible. The FBI also recommends blocking port 22 access, which would prevent encrypted remote access, and investing in robust staff training programs so they know not to let outsiders plug hardware into their machines. ®

India's Computer Emergency Response Team (CERT-In) says defenders should endevor to patch or mitigate exploited n-day vulnerabilities within 12 hours as the cybercrime landscape continues its AI-ification. The organization's recommended half-day window applies only to bugs that affect internet-facing or "crown jewel" systems and are known to be exploited. In these cases, CERT-In told defenders to "patch, mitigate, or remove exposure within 12 hours where feasible." For other flaws, such as a standard critical vulnerability (CVSS 9.0 or higher) affecting an internal system, or a known exploited bug affecting an internal system, defenders can enjoy a much more leisurely 24-hour window. The revised suggestions come as part of a new guide released by CERT-In this week to help infosec pros better protect against AI-assisted cyberattacks. "AI-assisted cyber exploitation reduces the time required for adversaries to identify, weaponize, and exploit vulnerabilities, exposed services, weak identities, insecure APIs, and misconfigured systems," CERT-In's report reads. "As organizations become increasingly dependent on interconnected digital infrastructure, cloud ecosystems, software supply chains, operational technologies, and AI-enabled platforms, the potential impact of AI-enabled cyber threats continues to increase across sectors." CERT-In's report follows a trail of news stories in 2026 that all suggest AI is becoming an increasingly important part of cybersecurity for both attackers and defenders. The field of agentic AI has especially matured rapidly in the past year. Consumer-grade tools like OpenClaw have made it easier for non-technical users to experiment with autonomous tech, raising its profile and awareness of its capabilities. Agents are equipped with all the necessary permissions to make significant system changes, but as global intelligence agencies recently highlighted, their behavior can at times be unexpected, and they're also prone to mischief. Security pros are starting to see the potential for AI agents in their workflows, but for attackers, the technology represents an opportunity to hasten all parts of their process, from recon and exploitation to privilege escalation and data theft. CERT-In cited agentic AI as one of the core concerns behind the report's recommendations, and because of the disparate supply chains on which organizations are increasingly reliant, any vulnerability can lead to cascading damage on interconnected systems. Beyond agentic AI, the launches of frontier models such as Anthropic's Mythos and OpenAI's GPT-5.5, two certified cyber workhorses, threaten to empower attackers further with capabilities to uncover and exploit critical vulnerabilities at pace. A 12-hour window: Is it feasible? Any cybersecurity practitioner will attest to the onerous nature of the patching process, and how it's not as easy as clicking "Update," which is why a 12-hour patch window might seem initially unrealistic to some. Urgent warnings and demands for immediate patching are routinely delivered alongside critical vulnerability disclosures, but these fail to account for the downtime required to apply patches, or the testing required to prove that by applying them, everything else won't break. Microsoft has had its fair share of these cases, for example, and many readers will have borne the brunt. CISA's Known Exploited Vulnerabilities catalog is another prominent resource that sets patching deadlines, albeit only for federal agencies, but these are typically set at two to three weeks, or a number of days for the most serious vulnerabilities. The cybersecurity pros who spoke to The Register, weighing in on the CERT-In recommendations, agreed that 12 hours is far too short a window to properly test and deploy a patch, although they said the organization was on to something with its approach. Dray Agha, senior manager of security operations at Huntress, said that CERT-In’s recommendation to "patch, mitigate, or remove exposure within 12 hours where feasible" was solid advice, largely because of the caveat that it doesn’t necessitate a full patch within that time. "By explicitly encouraging temporary mitigations, such as isolation, access restriction, or disablement until a patch is ready, this turns the patching deadline into a highly feasible and necessary containment strategy," Agha told The Register. "And this corroborates the guidance we dispense at Huntress for critical threats: we often advise our community to deploy temporary mitigations to 'get them out of trouble' as soon as humanly possible, and then come up with a more coordinated strategy for patching that respects the business's need to function in its enterprises." Agha added that AI-assisted cyberattacks are seen every day in the wild, compressing the time taken to exploit vulnerabilities, meaning defenders must adapt to this new reality. In the pre-AI days, a 12-hour window to mitigate or patch a known exploited vulnerability was seen as excessively tight, but increased availability of advanced tooling and automation is reshaping the demands of vulnerability management. "Defenders must fundamentally reshape their operations to focus on quicker mitigations – prior to AI, at Huntress, we have seen vulnerabilities exploited within a handful of hours, let alone a full 12 hours," said Agha. He said the 12-hour guideline is less about an arbitrary clock, more about "forcing a necessary readjustment in how organizations drive their security approaches to be beyond compliance and move to a continuous defensive posture. "And this will involve the enterprise functions of the business being a part of the security posture – not just IT, thank you very much – as the consequences of AI-driven exploitation mean faster, higher impact cascading negatives on a targeted business; much better to proactively defend than reactively recover." ®

A security researcher found a foolproof way to guarantee tech conferences accept his speaker submissions: hack their systems. CVE-2026-41241 is a stored cross-site scripting (XSS) vulnerability in pretalx, a popular open source tool that conference organizers use to manage speaker submissions and schedules, that could allow attackers to effectively take over an organizer's session. Any user controlling searchable fields – including submission titles, speaker display names, and user names or email addresses – could inject arbitrary HTML or JavaScript. When an organizer's search query matched the malicious record, the payload would execute in the organizer interface. "Once triggered, the injected script executed in the context of the pretalx organiser interface and could read the page's [Cross-Site Request Forgery] CSRF token, submit authenticated requests on the victim's behalf (including requests modifying data due to access to the CSRF token), or exfiltrate data visible to the victim," according to pretalx's security advisory. Project maintainers patched the flaw in April, and it has been fixed in pretalx 2026.1.0. Elad Meged, founding engineer and security researcher at AI penetration-testing and offensive-security startup Novee, found and disclosed the flaw when he was preparing conference speaker submissions. He noticed the exact same call for proposals (CFP) submission form appearing underneath all of these different hacker conferences and academic symposiums' logos. 'One codebase serving them all' While the events are unique, with different parent companies and organizers, "underneath, it is one codebase serving them all," Meged said in research published on Wednesday and shared in advance with The Register. Meged then used the flaw to auto-apply for 40 conferences - and got accepted to present his proposed talk, "Securing Modern Web Apps," at every single one of them. While Meged did submit real entries, he did not submit a live exploit payload into the conference systems. The Novee team validated all of their findings on a local instance. They didn't do any testing on pretalx.com or a third-party-hosted instance. "The goal was to validate the vulnerable workflow in the exact real-world setup while avoiding unnecessary harm," Meged told The Register. "So, we used realistic, normal-looking talk submissions and then validated exploitability through controlled, version-specific testing." Some of the events that use pretalx-based CFP infrastructure include OffensiveCon, TROOPERS, FOSDEM, HEXACON, and Recon, he told us, stressing that this does not mean any of these conferences were actively exploited or compromised. For any conferences that used pretalx for talk submissions, but weren't accepting submissions at the time, Meged followed up with them via responsible disclosure. And yes, Meged admits that he could have had more fun with the talk title, but he wanted to make it "intentionally boring and plausible," to blend in with other proposals. "I agree something outrageous would have been funnier, but it would also have been less responsible," he said. Human led, AI agent assist Meged described the research as "human-led vulnerability research, agent-assisted at internet scale." Once they understood the type of vulnerability, any "capable web security researcher" could reproduce the exploit, he said, adding "this would not require nation-state-level skill." Scaling the attack, reliably reproducing it, and adjusting the attack chain to each real-world pretalx deployment, however, benefited from an agentic AI assist – and this wasn't "a one-off script or a prank CFP submission," he told us. "Different pretalx versions, deployment choices, and enabled features can change the behavior," Meged said. "Something that works on one instance may fail on another or require a different validation path." Plus, some conferences use hosted infrastructure, while others run their own self-hosted instances. So the security shop built an agentic fingerprinting and validation system to scan the internet for public-facing, vulnerable systems, learn as much as possible about the version and configuration, and find the best way to exploit them. 'This type of work does not scale manually' "This type of work does not scale manually," Meged said. "A human can find the core idea, understand the primitive, and make the responsible disclosure decisions. But mapping internet-wide exposure, fingerprinting many deployments, comparing versions, modeling behavior, adjusting validation logic, and organizing disclosure steps is exactly where AI agents become useful. The agents helped with discovery, fingerprinting, version comparison, environment modeling, controlled validation, note-taking, and disclosure workflow management." After finding and fingerprinting public pretalx deployments, and identifying version-specific behavior, the agents selected the best non-destructive validation path for each one. While there's no indication that attackers found and exploited the security issue before Novee's team, it's serious in that it could have granted organizer-level access to the conference call-for-proposal and scheduling system - these typically contain speaker identities, submissions, acceptance decisions, and private communications between conference organizers and speakers. Gaining access to this type of information could have allowed for targeted phishing or other trust-based attacks impersonating a well-known industry event. "With organizer-level access, an attacker could potentially read or modify submissions, interfere with the review process, impersonate conference staff, alter CFP data, or communicate with speakers and submitters from a trusted conference context," Meged said. "The most realistic abuse case is targeted phishing or lateral movement through trust. If a speaker, sponsor, reviewer, or attendee receives a link or request from what appears to be a legitimate conference system, they are much more likely to trust it," he added. "So the story is not just: Someone could get a fake talk accepted. The bigger risk is that a trusted conference platform could become a launchpad for attacks against the entire event ecosystem." Tobias Kunze, a developer who created pretalx, told The Register that Meged reported 11 security findings on April 14, he assessed all of these and classed one as a serious vulnerability and five as non-vulnerability bugs – but with fixes – and five more as non-critical or intended behavior. "Contact with Elad was very positive and professional," Kunze told us. "We discussed the severity and impact of his findings, and it was as good a report as a small open source project like pretalx can hope to receive." ®

Crims found the soft spot in the company's security. MyPillow, the US-based bedding brand founded by election conspiracy theorist Mike Lindell, has been listed by Play ransomware extortionists as an alleged victim. The pillow shop first appeared on Play’s name-and-shame data leak site on Monday, with the gang threatening to leak stolen data by Friday if MyPillow execs don’t pay the ransom demand. While the extortionists didn’t specify how many gigabytes of data they allegedly stole from MyPillow, they claim it includes “private and personal confidential data, client documents, budget, payroll, IDs, taxes, finance information” and more, according to the dark-web post seen by The Register and shared on social media by threat-intel firm FalconFeeds. MyPillow did not immediately respond to The Register’s inquiries. We will update this story if we receive any response. As of May 2025, the FBI said Play ransomware operators had allegedly exploited about 900 organizations, and the crew’s ransomware variant consistently ranks among the top five targeting critical infrastructure. Play previously stole around 65,000 Swiss government files after breaching its IT supplier Xplain in 2023. A year later, the group hacked Microchip Technology. The American semiconductor manufacturer told regulators that the ransomware attack disrupted some of its business operations and cost it $21.4 million in expenses related to the security incident. North Korean government goons have also used Play ransomware in their intrusions. Cisco Talos' incident responders previously told The Register that Play was one of the crews that used so-called "EDR killers" to disable endpoint security products in their ransomware infections. MyPillow is probably best known for its founder and CEO's politics. Lindell is a major proponent of President Trump’s false claims that the 2020 election was stolen, and is now running for Minnesota governor. ®

National security and digital forensics experts have called foul on Nigel Farage's "disturbing" and unsubstantiated claim that Russia was behind the leak of a story about the UK politician receiving a £5 million gift from a crypto billionaire. Sources inside Farage's right-wing Reform UK told the Mail on Sunday that the party leader believes Russian spies hacked his phone and relayed details about Christopher Harborne's gift, a matter of which only four people were aware. Farage was said to have engaged outside "counter-espionage experts" to perform a technical analysis of his device – analysis that was said to point to Russia. According to Peter Sommer, professor of digital forensics at Birmingham City University, whichever outfit was entrusted to carry out this work would have been looking for two different types of markers to prove Russia was involved. These would be either the phishing message Farage clicked on that allowed Russia to access his private communications or the malware code an attacker used to exfiltrate them. "It's obviously trivial to disguise the source of an email, so that doesn't help," Sommer told The Register. "And the second thing is if you're talking about looking for hacking codes, hackers, whether they are juveniles or people in major SIGINT systems, are likely to be stealing from each other, so there's nothing unique about a code that would say where it comes from." Sommer also highlighted that advanced intelligence powers have tools at their disposal to obfuscate the source of malicious code. The CIA's leaked Marble Framework supposedly had the ability to translate malicious code into any language, including those used by its chief adversaries. "Now, absent from that, how on Earth do you determine that this is a Russian hack?" Sommer asked. Neither Farage nor Reform UK has spoken officially on the alleged Russian phone hack. They have not specified which experts on whose conclusions they used to make the claims, they have not stated what evidence pointed to Russia's involvement, and they have not committed to making this forensic assessment available for public scrutiny. Opening up the data for verification was one of the core issues raised by Ciaran Martin, founding chief executive of the UK's National Cyber Security Centre (NCSC), who labeled Farage's claims "disturbing" and "without any merit." Speaking to The Guardian, Martin said that not only is the lack of clear evidence concerning, but also if Russia was behind the hack-and-leak operation, a deliberate attempt at destabilizing a foreign democracy, then it would have significant consequences for the UK's Russia policy. "An aspiring prime minister has essentially claimed that Russia has launched an unprecedentedly aggressive intervention – a malicious intervention – in British politics, and he's not produced a shred of evidence to support that claim," Martin said. "It is a very, very serious thing to allege. It would be a national security issue," he added. "If it is true, the government should be in emergency session in COBR right now, considering their response to the most serious Russian intervention in internal British affairs for years." He said the claims published by the Mail on Sunday, at present, are unsubstantiated, and if true, in normal circumstances, this would prompt a formal government response. The Reg understands that the NCSC has not been engaged by Farage or Reform UK over the matter. The National Crime Agency did not respond to questions regarding its involvement and the Metropolitan Police Service declined to comment. Reform UK did not respond to our requests for more information, nor did Nigel Farage's office. What exactly did Reform UK claim? According to sources who spoke to the Mail on Sunday, Russian spies hacked Farage's phone, ascertained details about Harborne's £5 million donation to the party leader, and leaked it to The Guardian, which first reported the story. The Guardian said at the weekend that Farage is now under "mounting pressure" to prove his claim about the Russian phone hack. There is no indication the Graun 's reporting was connected to any illegal activity or Russian spies, but Farage is implying so, telling the Mail on Sunday: "This shocking revelation brings into question The Guardian’s judgment and whether Reform can cooperate with them in future." According to the analysis of Farage's phone, carried out by the unidentified counter-espionage experts, the findings were "almost certainly linked to Moscow," the Reform UK source said. They also claimed that spear-phishing tactics were used to compromise his phone, email, and bank accounts. "It bore all the sophisticated hallmarks of a nation-state actor using destabilization techniques in the run-up to this month's local elections," the source added. Farage said: "These actions by Russia are deeply concerning and highlight the threat they pose to British security." Regarding the motive for such an attack, Reform UK believes its leader angered Russian president Vladimir Putin by previously expressing support for NATO. He has said in the past that UK forces should shoot down Russian aircraft if they enter NATO airspace, and joined controversial calls for Ukraine to be admitted to the military alliance. The party also said that Harborne may be a target for the Russian regime because he joined former prime minister Boris Johnson on a trip to Ukraine in 2022, designed to showcase the impact of Russia's invasion earlier that year. ®

Anthropic has revealed its intention to one day release models that match the performance of its Mythos bug-finding AI to the public, once it can make them safe. In case you came in late, in early April Anthropic announced it had developed a model called Mythos that is so good at finding security vulnerabilities in programming code that the company decided to offer it only to select entities because allowing unfettered access would mean cybercriminals could quickly discover and exploit software flaws. That access program is called “Project Glasswing” and participants report it quickly finds many bugs but few that humans couldn’t find given enough time and resources. Those with access to Mythos have also sometimes said the quantity of bugs it finds somewhat overwhelms their ability to patch them all. The mere existence of Mythos has sparked a little panic – Japan’s government ordered a sweeping security review and Indian authorities demanded a patching spree at financial institutions – plus a general realization that even lesser AI models are also decent bug-finders, meaning cyber-defenders must now expect attackers will weaponize more flaws, more often. No company—including Anthropic—has developed safeguards strong enough to prevent such models from being misused Anthropic last week published an “initial update” on Project Glasswing that in its second-to-last paragraph reveals the company’s next step will see it “… work with critical partners – including US and allied governments – to expand Project Glasswing to additional partners. And in the near future, once we’ve developed the far stronger safeguards we need, we look forward to making Mythos-class models available through a general release.” The company didn’t explain what it means by “near future” and admits that “At present, no company—including Anthropic—has developed safeguards strong enough to prevent such models from being misused and potentially causing severe harm.” Further illustration of that assertion can be found earlier in the company’s post, which reveals that Anthropic has used Mythos to scan more than 1,000 open-source projects that it says “collectively underpin much of the internet – and much of our own infrastructure.” To date, Mythos has found an estimated 6,202 high-or-critical-severity vulnerabilities in these projects – and 23,019 flaws in all. The post reveals that when Mythos finds a flaw, Anthropic and its pals in the security community reproduce the issue that Mythos has found and “re-assess its severity.” “Once we’ve confirmed that a vulnerability is real, we check for whether there are already fixes in place, and write a detailed report to the software’s maintainers,” Anthropic explains. “We take considerable care here: on top of the regular challenges of maintaining open-source software, maintainers have been facing a deluge of low-quality, AI-generated bug reports. Indeed, several maintainers have told us they’re currently severely capacity constrained, and some have even asked us to slow down our rate of disclosures because they need more time to design patches.” 1,752 of the high-or-critical-rated vulnerabilities Mythos found in FOSS have gone through that process and 90.6 percent (1,587) proved to be valid flaws. Of those, 62.4 percent (1,094) “were confirmed as either high-or-critical-severity,” the post states. One of the critical flaws impacted the wolfSSL cryptography library used by billions of devices worldwide. “Mythos Preview constructed an exploit that would let an attacker forge certificates that would (for instance) allow them to host a fake website for a bank or email provider,” Anthropic wrote. “The website would look perfectly legitimate to an end user, despite being controlled by the attacker.” Thankfully, developers have already patched wolfSSL, and Anthropic said it will deliver a full technical analysis “in the coming weeks.” Keep an eye out for CVE-2026-5194 to learn more about this one. Mythos is adding to an already overloaded security ecosystem “75 of the 530 high-or-critical-severity bugs we’ve reported have now been patched, and 65 of those have been given public advisories,” the post states, then explains that low fix rate by revealing Anthropic is “still early in the 90-day window that’s set out in our Coordinated Vulnerability Disclosure policy: we expect many more patches to land soon.” The company thinks it is also “likely to be undercounting patches because some vulnerabilities are patched without a public advisory.” Lastly, the flood of bugs Mythos found “is adding to an already overloaded security ecosystem.” Anthropic’s suggestion for security teams struggling to develop fixes for bugs AI discovered is, unsurprisingly, more AI such as skills that improve its Claude model’s ability to help developers. ®

OPINION Dirty Frag, Copy Fail, and Fragnesia are less a random cluster of Linux bugs and more the public unveiling of how AI tools can pry open security holes with just a prompt or two. What they also have in common is their shared abuse of a core kernel abstraction: The page cache. What does this mean for you and me? Is this the rainstorm before a downpour of killer Linux security problems, or is this just a shower? It depends on who you ask. Whatever else may be true, these problems must be addressed. As Igor Seletskiy, CEO of CloudLinux, said: "The real story here is that we typically see one or two kernel-level LPE (Linux privilege escalations) vulnerabilities that affect multiple distros/versions per year. And now we see two such vulnerabilities one week apart. We should expect this trend to continue for quite a few months, meaning companies might have to reboot servers weekly." Ouch! But is this the start of a trend? Linus Torvalds, who knows a thing or two about Linux, said at Open Source Summit North America in Minneapolis that until recently, the kernel community would quietly notify distributions about a bug and ask them to upgrade without detailing the vulnerability, and "most of the time, nobody would figure out what happened." That was then. This is now. With AI‑accelerated analysis, he recalled that "last week, we fixed the bug; within three hours, there was a blog post about the implications of that bug fix, because security people love getting attention." As a result of this kind of thing, Torvalds has changed how the Linux security community will deal with AI-discovered security holes. "AI-detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved – and only makes that duplication worse because the reporters can't even see each other's reports." In addition, Torvalds added, in the case of AI-discovered bugs, you need to keep in mind that just "because you found it with AI, 100 other people also found it with AI." That means we're going to hear a lot more about Linux security problems. But are they getting worse? I asked Greg Kroah-Hartman, the Linux stable kernel maintainer, and he told me: "Maybe? It's hard to tell; the 'recent' ones really are very minor, as the number of systems that have 'untrusted users' is not common anymore. I don't see any real uptick in our actual bug fixes that I can tell." He continued: "We fix bugs like that on a daily basis, it's just the rise of people wanting to 'name a bug' and release a public exploit seems to be all the rage at the moment." An important point that Chris Wright, Red Hat's CTO, made at Red Hat Summit, the week before, is that in "security, all things aren't created equal. There will always be a spectrum of vulnerabilities that will surface. Some of those will be really critical and we will need to respond very quickly, so that becomes a clear priority. Others will have a longer tail of lower severity." Torvalds also added at Open Source Summit that just because you read stories about Linux and AI-discovered bugs, you shouldn't think the same thing isn't happening to proprietary software, such as Windows. "If you think that AI can't reverse engineer closed source, you're in for a surprise." In fact, he warned, "closed source is even worse in this respect, because the AI can't help you fix those problems, but the AI sure can help find those problems in the first place." He also discouraged security researchers from publishing working exploits: "When it comes to things that really are security issues, you may not want to make the exploit public… Don't be that guy who then crows about it publicly and says, 'Look, I could bring down this big company.'" Following on this theme, Christopher "CRob" Robinson, chief security architect for the Open Source Software Foundation (OpenSSF), told The Register that thanks to AI, "roughly 30 percent of reported Linux security bugs were duplicates. That's going to be another problem in this AI age, where everybody's a researcher, right, with a $20 cloud code account." That, in turn, will burden already overworked maintainers with yet more patches to deal with. Linux, Torvalds added, is something that its maintainers can handle. Smaller open source projects, however, are all too likely to be overwhelmed. The real problem, according to what the Google Threat Intelligence Group has discovered, is that the mean time to exploit (TTE) for vulnerabilities has continually decreased "from 63 days in 2018 to -1 day in 2024 and further downward to an estimated -7 days in 2025. A negative number indicates that exploitation of a vulnerability, on average, occurred before a patch was released." So what does this mean? Yes, we're going to see a lot more security vulnerabilities showing up in Linux and other open source projects. Yes, some of them will be serious, and all too many will have exploits out before the patches arrive. It's not, however, that Linux has suddenly become less secure. It's that AI eyes are much better at detecting bugs than human eyes have ever been. We will catch up, and AI can help with that, too. In the meantime, system administrators and developers will have to be more security-conscious than ever before. As Wright told The Reg, it's high time we switched from using SELinux in permissive to restrictive mode. Enforcing strict security is a pain, but what's even more of a pain is having to rebuild your containers and servers after a serious attack gets through. ®

A solo Russian-speaking threat actor used a jailbroken Google Gemini in a fraud and credential-theft campaign targeting hardcore Trump supporters and conspiracy theorists. Between September 2025 and May 2026, the “low-skilled” scumbag using the handle bandcampro partnered with the LLM to impersonate an American veteran, run a Telegram channel (@americanpatriotus), hack admin credentials, and steal cryptocurrency, according to a threat report from TrendAI. His only "real cost" in the operation was stolen API keys. Bandcampro ultimately reached about 17,000 subscribers, used 73 likely-stolen Gemini API keys, hacked 29 WordPress admin credentials, infiltrated at least one company, and emptied at least one victim’s cryptocurrency wallets, according to TrendAI researchers Philippe Lin, Joseph C Chen, Fyodor Yarochkin, and Vladimir Kropotov. The threat-hunters detailed the campaign in a Thursday report, and said while the Telegram channel dates back five years, bandcampro’s success skyrocketed once he started using AI-generated content last fall. "We have reached an inflection point for cybercrime conspiracies,” Tom Kellermann, TrendAI’s VP of AI security and threat research, told The Register, adding that “bandcampro's conspiracy underscores the sophistication of the Russian cybercriminal community and how weaponized jailbroken LLMs are manipulated to orchestrate a systemic cybercrime campaign.” Kellermann said the attack “highlights LLMs' Achilles heel, which is the tremendous exposure to API attacks." TrendAI researchers discovered the scammer’s infrastructure in May, which exposed the full contents of the individual’s operational environment. He used Google Gemini to generate the Telegram channel text and Venice.ai to power an interactive chatbot designed to simulate a Quantum Financial System (QFS) terminal. Neither Google nor Venice responded to The Register’s requests for comment. The campaign targeted the QAnon and MAGA communities, mimicking the cryptic, anonymous “Q drop” messages at the heart of the QAnon conspiracy, but the researchers say his “use of information operation techniques was more likely for cryptocurrency fraud instead of political motives,” based on the content posted, and the stock remote access trojan (RAT) used alongside other commercial malware. On September 9, 2025, the actor posted a fake "freedom-first, self-custody wallet" called StellarMonster, with a welcome bonus of up to 1,000 XLM (about $380) on the Telegram channel. It was an executable named StellarMonSetup.exe. Malware analysis determined that in reality, StellarMonSetup.exe is a legitimate remote access tool called GoToResolve, which gives the operator a persistent remote desktop session with file access, command execution, and clipboard capture. Plus, any subscribers who used the "import your wallet" function and typed their seed phrase into the fake import screen gave the attacker their wallet keys. “At least one victim's crypto-wallet was fully compromised: password cracked, 12-word mnemonic stolen, and the owner's 40+ wallet addresses harvested across all major chains,” the researchers noted. The attacker also used an AI-powered brute-forcing tool to hack WordPress accounts, we’re told. “The script is built on the premise that people mutate familiar base passwords in predictable ways, and Gemini 2.5 Flash can model the mutations when supplied with static wordlists,” Trend wrote. In total, the AI-assisted WordPress hacking operation cracked 29 WordPress administrator accounts, including those belonging to weapons retailers, legal offices, medical practices, and small commercial sites. During his conversations with Gemini, bandcampro asked questions like: “When the bot accumulates 5,000 active users, how much can we earn from one pump-and-dump cycle?” The criminal also asked how professional crypto call centers scam North American victims and Gemini suggested Medicare and/or Health Canada fraud targeting the elderly. The Russian speaker also automated his content campaign through a pipeline he named "Quantum Patriot," a set of Python scripts that called Gemini to role-play as an American veteran patriot. The pipeline fed a preset list of newsfeeds into the LLM and Gemini rewrote them, prompted to act as an admin of an “American Patriot” channel looking for “hidden angles.” The crypto- and credential-thief also used Gemini to help him hack, set up a command-and-control framework - including a mail-testing tool, a Gmail aggregator, and an anonymous proxy on a VM in the Netherlands - steal and validate credentials, and run the chatbot. “In the anatomy of one busy working day, Gemini deployed servers, helped debug code, automated workflows, wrote a script to rotate API keys, and managed the actor’s Cloudflare tunnels,” the TrendAI researchers wrote. “The actor prompted in Russian, while the LLM reasoned and replied in English. Over one 16-hour session, the actor co-worked with Gemini end-to-end." At one point, after a nine-hour pause from the human partner, which the authors say “was likely a 9-hour sleep,” bandcampro found the bot posting every 20 minutes without a break - but with Russian slang appearing in the English posts. So he opened another session to fix it. “What previously required a team of writers, social media managers, IT workers, and malware programmers can now be automated by a single actor using a VPS, a Telegram bot, and API access to frontier models,” Trend’s team warned. ®

A malware-spreading scumbag swimming through GitHub pushed malicious commits to more than 5,500 repositories on Monday as part of an automated campaign called Megalodon. Similar to the earlier TeamPCP attacks that poisoned about 3,800 GitHub repositories, this new campaign has so far infected 5,561 repos with CI/CD credential-stealing malware, according to SafeDep researchers, who uncovered the predatory commits and published a full list of the compromised repositories. If a repository owner merges the commit, the malware executes inside their CI/CD pipeline and propagates further, Ox Security lead researcher Moshe Siman Tov Bustan said in a Thursday blog post. Megalodon steals AWS secret keys and Google Cloud access tokens. It also queries AWS, Google Cloud Platform, and Azure metadata for instance role credentials, reads SSH private keys, Docker and Kubernetes configurations, Vault tokens, Terraform credentials, and scans source code for more than 30 secret regex patterns. Then it exfiltrates GitHub tokens, including secrets used to authenticate with cloud providers, thus allowing attackers to impersonate developers’ cloud identities, along with Bitbucket tokens. In other words: consider ALL of your CI/CD variables pwned. "We’ve entered a new supply chain attack era, and TeamPCP compromising GitHub was only the beginning,” Bustan told The Register. “What’s coming next is an endless wave, a tsunami of cyber attacks on developers worldwide.” Plus, he added, hacking GitHub “compromises the security of every company with a private repository hosted on the platform.” This new wave of supply chain attacks hitting developers’ environments won’t stop until “companies like npm and GitHub take serious action against the spread of malicious code on their servers,” Bustan said. He noted npm’s statement on X saying it “invalidated npm granular access tokens with write access that bypass 2FA” to prevent additional supply-chain attacks like Mini Shai Hulud. “That could help a little with account hijacking, but it doesn’t solve the actual problem,” Bustan said. “Malicious code is still reaching their servers, and nothing is stopping it before it does.” npm … but not TeamPCP SafeDep spotted Megalodon hidden inside a legitimate package: Tiledesk, an open source live chat and chatbot platform. The attacker backdoored versions 2.18.6 (May 19) through 2.18.12 (May 21), and the same npm maintainer published the last clean version, 2.18.5, before unknowingly publishing these newer compromised versions. “The attacker never touched the npm account,” the open source supply-chain security startup researchers said. “They compromised the GitHub repository, and the maintainer published from the poisoned source without realizing it.” While publishing malicious packages on npm is a TeamPCP signature move, Bustan said there’s no threat-intel or code-analysis evidence that connects Megalodon to the crew behind the Trivy, Checkmarx, and other recent supply-chain attacks. “Our best guess now is that it's a different threat actor copying their behavior and style, but not much of the code itself,” he told us. And despite TeamPCP open sourcing its Shai-Hulud worm and announcing a supply-chain attack competition on BreachForums, Ox doesn’t believe Megalodon is a contest entry. “We have indications that they are not participating in the TeamPCP contest due to the contest having a specific rule to add a public encryption key that the actor behind the malware could match with his private key to prove his involvement,” Bustan said. Who is built-bot? SafeDep’s threat hunters traced the malicious commit (acac5a9) to an author “build-bot,” connected to the email address build-system[@]noreply.dev with the message “ci: add build optimization step.” The author name and noreply email mimic automated CI commits, and there’s no GitHub account linked to the author and committer user fields. “Someone pushed the commit to master with no PR and no merge commit, using a compromised PAT or deploy key,” according to the researchers. They searched GitHub for other commits authored by the same email address and found 2,878 results, plus a second email, [email protected], with an additional 2,841 commits. All landed May 18 during a six-hour window (11:36 to 17:48 UTC) and targeted 5,561 repositories. This includes nine compromised Tiledesk repositories: tiledesk-server, tiledesk-dashboard, tiledesk-telegram-connector, tiledesk-llm, tiledesk-docker-proxy, tiledesk-community-app, tiledesk-campaign-dashboard, tiledesk-helpcenter-template, and tiledesk-ai. Others include Black-Iron-Project with eight compromised repos, WISE-Community, and hundreds of smaller repositories. ®