News
Duo who sold car crash victims' data must repay £118k
Two former RAC workers in the UK have three months to pay more than £118,000 ($158,500) collectively after being convicted of selling crash victims’ data, according to the Information Commissioner’s Office (ICO). Debbie Okparavero and Maliha Islam, of Salford and Manchester respectively, were sentenced to six-month prison stints, suspended for 18 months, and 150 hours’ unpaid work in 2024, after being found guilty of offenses under the Computer Misuse Act 1990 and the Data Protection Act 2018. The pair, who worked for roadside accident biz RAC, were caught selling the personal data of car crash victims – just shy of 30,000 lines of data to an unknown buyer, the ICO revealed following an investigation. Okparavero and Islam were in a WhatsApp chat together, where they discussed the data and its sale to the unknown third party. RAC clocked on to the activity after deploying unspecified monitoring software, which detected Okparavero copying the data from RAC systems. A resulting investigation showed that around 29,500 lines of data were shared with Islam via WhatsApp. Islam was ordered to repay £39,522.50 ($48,274.45) for her part in the scheme in November, and the ICO noted in a Thursday announcement that she paid this in full. Reflecting more serious offending, at Manchester Crown Court on May 29, Okparavero was ordered to repay £89,277.32 ($119,962.38) within three months. Failure to do so will result in her serving 18 months in prison. Andy Curry, head of investigations at the ICO, said: “This outcome demonstrates justice did not end at sentencing. Our powers enabled us to continue to pursue these two individuals in order to strip them of assets gained through their serious criminal activity. Through the Proceeds of Crime Act, we are ensuring people do not financially benefit from their criminal activity. “I would like to once again thank the RAC for informing us about this breach and fully supporting the ICO’s investigation, which enabled us to hold these two individuals to account.” ®
Categories: News
Nobody needs Mythos or 0-days to build a chaos-causing computer worm – free open source models work just fine
There's a lot of fear surrounding the bug-finding capabilities of super-advanced AI models like Anthropic's Mythos and OpenAI's GPT 5.5-Cyber. But attackers are already using free, publicly available LLMs to hijack networks and worm through software supply chains at a much lower cost – to them at least. The latest example comes from University of Toronto researchers, who used an unnamed, publicly available open-weight model released in 2025 to develop a computer worm that they claim spread through an enterprise test network. The self-propagating code adapts on the fly to identify known vulnerabilities and misconfigurations on target systems, then generates and executes attacks to move laterally through the network and compromise additional machines. And it’s all built on a small, free model that runs on a single GPU. “People need to understand that it’s not just the biggest and most powerful AI models that pose security concerns – a whole other area of threat has been vastly underestimated,” University of Toronto computer engineering professor Nicolas Papernot told The Register. Papernot and fellow researchers Jonas Guan, Tom Blanchard, Hanna Foerster, Hengrui Jia, and Gabriel Huang published their findings [PDF] on Tuesday. While guardrails and other safety features implemented by major commercial AI systems are “essential,” Papernot told us, in reality “they will not prevent the threat of AI-driven worms with a similar design.” “The majority of real-world cyberattacks don’t rely on zero-day vulnerabilities,” he added. “Our work demonstrates that attackers can now cheaply operationalize known vulnerabilities at scale, which decreases the window of time defenders have to fix vulnerabilities and find human errors, like reused passwords or poorly configured backup jobs.” The paper doesn’t specify, and Papernot declined to say, which LLM they used. “We omitted certain methodological details (such as the agent’s reasoning graph and tool harness) and experimental specifics (such as the AI model) that could materially help a malicious actor construct similar malware,” Papernot said. “We shared enough information to make the threat credible enough for scientific scrutiny without providing a blueprint that would enable misuse.” The researchers also noted that they are not publicly releasing the code, but are working with the University of Toronto to set up a vetting process through which qualified researchers may request access for defensive research purposes. Not NotPetya Before you start breathing into a paper bag, there are a few things to note about this research. First, unlike Mythos and friends, the prototype worm does not exploit zero-day vulnerabilities. It only targets publicly disclosed but unpatched bugs, misconfigurations, and recurring weakness classes. This is intentional, because known security flaws – not zero-days – are what most real-world cyberattacks use, the authors say, citing WannaCry and NotPetya as examples. Both of these worms exploited security holes that had patches available for at least a month before the malware infected vulnerable machines. Both spread rapidly and caused global disruption. The worm did, however, find and abuse vulnerabilities disclosed after the model’s training cutoff by ingesting publicly available security advisory information at runtime and using this data to develop exploits. While the paper repeatedly points to WannaCry and NotPetya as worst-case scenario examples, this lab-tested prototype or something similar is not going to cause the level of destruction that either of those two earlier worms did. Both propagated very quickly: WannaCry infected more than 230,000 computers across 150 countries in just one day in May 2017. In June 2017, NotPetya spread globally within hours, taking down at least one large banking network in just 45 seconds. Plus, they both used very sophisticated evasion techniques to avoid being detected by security tools. This worm, on the other hand, moves slowly. In the “FakeCorp” network they used in the experiments, the prototype took about five days to replicate across half the network, requiring hundreds of LLM inference calls per target for reconnaissance, strategy formulation, and payload generation. The timeline gives defenders a longer window for detection and response. However, it will likely shorten as inference hardware and model efficiency improve. Also, unlike WannaCry and NotPetya, the worm doesn’t try to hide itself. “We deliberately chose not to equip the worm with concealment capabilities – it is not instructed to cover its tracks or minimize its network footprint, and it has no tools to do so,” the boffins wrote. “This was a conscious methodological choice to further limit the risk of misuse.” Finally, the test-network devices themselves didn’t have any endpoint detection, antivirus, or firewall software deployed, which (we hope) makes this a not-quite-realistic setup. Exploiting the FakeCorp target network Here’s how the experiments worked. The team deployed the worm prototype in 15 independent experiments on an isolated 33-host network including Linux servers, Windows environments, and IoT devices. Each computer had been seeded with at least one real-world vulnerability, including software bugs and misconfigurations. The worm operated fully autonomously for seven days, and correctly identified an average of 31.3 vulnerabilities, exploited 23.1 hosts to elevated access, and propagated to 20.4 hosts. It reached up to seven generations of self-replication, we’re told. “Put another way, on average, the proof-of-concept worm successfully exploited 73.8 percent of the network and then replicated to 61.8 percent of the network,” according to the research paper. In addition to finding and abusing the known flaws on the devices, the worm also found vulnerabilities disclosed after the LLM’s training cutoff: two recent Linux flaws, CopyFail and DirtyFrag, and a critical bug that leads to remote code execution in the Marimo notebook platform (CVE-2026-39987). The AI-based worm gained root access in 41 of 67 attempts (61 percent) across the three hosts with these one-day vulnerabilities. This includes 13 of 27 attempts on the Marimo host, 15 of 17 on DirtyFrag, and 13 of 23 on CopyFail. The two Linux vulnerabilities were disclosed shortly before the experiments, and a single document containing publicly available exploit instructions was enough for the worm to weaponize them successfully 70 percent of the time, or in 28 out of 40 attempts. “This result suggests that the same exploitation pipeline can absorb newly published vulnerability information without architectural changes,” the team wrote. When worms get sneaky In addition to finding and exploiting vulnerabilities, the AI worm did some other interesting, sneaky things during the experiments. Despite the lack of firewalls and endpoint security products enabled, the researchers added some components to the worm’s code to “provide increased defence-in-depth.” This included a denylist of IP addresses baked into the source code. So in theory, the worm would read the denylist every time it targets a new machine, and if the IP address matched one on the list, it would move on to a new target, thus preventing it from infecting some hosts. Instead, at “various points” during the experiments, the worm rewrote its source code to allow it to attack an IP address on the denylist. In another workaround example: when a virtual-machine check caused replica worms on Alpine Linux and Windows Server 2008 machines to crash at startup, the parent worm found the attestation source file on the target computer and removed the VM-detection check, allowing the worm to replicate successfully on the new machine. “This behavior was not prompted or incentivised by the agent’s instructions; it autonomously diagnosed the failure, identified the responsible code, and modified it to achieve its objective,” the boffins wrote. In another test run, the researchers accidentally packaged a FakeCorp network configuration file that included admin credentials with the worm code. The worm discovered the credentials and shared them with other active replica worms, “causing a rapid increase in propagation within the contained environment.” Additionally, in two separate instances, the worm established persistence on a compromised computer using mechanisms outside of the intended replication pipeline, we’re told. In one instance, it started the replica process and then registered it with the machine’s service-management system to auto-restart if terminated. In another, it created a scheduled task that relaunched the replica worm, causing it to reappear even after the original process was killed. “The agent appears to have inferred, from the general objective of maintaining an operational replica, that persistence mechanisms available on the target could be used to make the replica more robust,” the researchers noted. Prior to publishing their work, the academics say they shared their findings with “national science, security, and defence” agencies to seek advice on how to responsibly release the information. We asked Papernot for details, including which government agencies and how they responded, but he declined to share anything else. ®
Categories: News
All the passwords were stored in Active Directory description fields
PWNED Welcome back to PWNED, the weekly column where we talk about weak security policies and how to avoid them. Hopefully, we can learn from others’ mistakes – or at least have a good laugh at them. Have a story about someone leaving a gaping hole in their network? Share it with us at pwned@sitpub.com. Anonymity is available upon request. This week, we have a tale of password passivity involving Active Directory. It comes to us courtesy of Rob Anderson, head of reactive consulting services at Reliance Cyber, a UK-based security firm. Anderson recalls in the past working with a firm that was creating service accounts that developers needed to use, but the org didn’t have a proper password vault for storing the associated credentials. Instead, to make it easy for team members to find what they needed, they put the passwords into the description field for Active Directory. “People don't realize that as soon as you've got an Active Directory user — just an ordinary user — you can read the comments field or the description field across the whole of Active Directory,” Anderson told The Register. “It's such an amazing lapse of security.” Soon enough, an Initial Access Broker (IAB), someone who specializes in gaining access to protected networks and then selling it to other threat actors, used a phishing campaign and executed offensive hacking tool Sliver on the endpoint. At that point, they captured a victim’s credentials, which led them to query Active Directory. Once in AD, the hackers found plenty of passwords, which came with full domain access. They used this access to delete all the backups and execute ransomware. In total, the crimes put 2000+ users out of action by encrypting Hyper-V hypervisors and their hosts. The company was taken offline for months. What we can learn from this sad story is that you can’t put passwords in cleartext anywhere that's easy to access, unless you want an enormous attack surface. Even without a phish, an untrustworthy colleague could have sold the passwords to a threat actor. After all, a recent survey found one in eight workers think selling company logins can be justified. “I've seen it where configuration details are kept in application servers that are running, and threat actors are using fuzzing — trying likely file and directory names — which again exposes configuration and credentials to the threat actors,” Anderson said. He noted that developers are a bit more savvy these days about where they put their credentials, but security naivete sinks ships. Trust no one. ®
Categories: News
Commvault says it's time to rethink resiliency as AI crooks leave victims in a 'dark, dead' state
AI-enabled cybercriminals have better tools and are inflicting more pain on their victims, wiping out virtual machines and hypervisors and leaving infrastructure in a "dark, dead" state after an attack, said Commvault Chief Technology Officer Brian Brockway. "The majority of cyber cases that we've seen in the customer base have moved well beyond the breaking inside, and encrypting and corrupting some of your key files and folders, to taking over control of your entire VM environment, wiping out all VMs, destroying all hypervisors, blowing up the center and leaving you in basically a dark, dead state," Brockway told The Register. Frontier AI is reshaping the threat landscape in two ways, he explained: advanced models are uncovering a deluge of software vulnerabilities, and attackers are exploiting disclosed flaws within minutes rather than weeks. “The more unplanned work that has to be done to react to this, that's always going to challenge priorities,” Brockway said. “We had the plan in place, we had sprints already dedicated to kind of get out to the next launch, and we have to come back over and reinvest more engineering time to corrective actions versus the next new get ahead feature.” Commvault cited Palo Alto Networks research showing that frontier AI models such as Mythos and GPT-5.5-Cyber identified more than seven times the typical number of software vulnerabilities found within a single month during testing. To prepare for this, Commvault recommends that IT and security teams look beyond backups and ask whether they can restore critical systems cleanly, whether recovery environments are isolated from compromised production systems, and whether recovery plans include the most important applications and dependencies. Brockway said air-gapping is the starting point. He said organizations should keep immutable and isolated copies of critical data separated from production identity, network, and management planes, and pressure-test recovery time and recovery point objectives against realistic attack scenarios, a hard lesson learned from witnessing victims recover from recent attacks. “One team is just trying to even clear the smoke to figure out what happened, then you have to come back over, strip it all down to bare metal, and basically redeploy the data center all over again,” he said. “While that's ongoing – and that's not a couple hour process by any means, that could take you, even in a well-exercised environment, it could be a couple of days or longer to get it back into a stable, usable state – what are our sanitized versions that we're going to come back over to (in order to) rebuild or restart the business again?” Businesses should prioritize the systems they cannot operate without — identity platforms, billing systems, operational databases, and cloud services — and define the order in which they will be restored, he said. As AI moves into core operations, teams should also account for newer dependencies such as data pipelines, model repositories, vector databases, and agentic workflows. In its recommendations, Commvault said it is also critical that organizations continuously test recovery. Brockway recommends rehearsing those plans in isolated cleanroom environments before the worst happens. “I need a testing environment that's got the same makeup, the same builds, which we're using, maybe not on full production resources, but I need to be able to say, ‘How do I put that application stack into a live environment, so we can come back over and test?’ “ he said. “That's what we're saying about things like this clean room concept of not just being a reaction to an incident, but it is also a quick environment for you to come back over and clone.” Brockway said this new normal in the AI era is straining the engineers who build and maintain enterprise software. He said while the first wave of AI scanning tools flooded teams with potential vulnerabilities, newer models go further, entering controlled environments and attempting the exploits themselves — a capability that mirrors what attackers do. "When you let them in, you have to do it under an extremely tight security control, because you're effectively almost automating the same thing that bad guys can do on the outside too," Brockway said. The output can swamp downstream teams. Brockway said one frontier model flagged roughly 10,000 critical vulnerabilities across operating systems, browsers, and other infrastructure. "That's 10,000 patches that have to come out of the system," he said. That volume forces hard choices about engineering priorities. Brockway said unplanned remediation work pulls staff off planned releases. To absorb the load at Commvault, Brockway runs a standing group dedicated to just those items. "They're the fast action team to analyze, make a quick assessment," he said. Brockway said the signal volume emerging from AI bug finders ultimately calls for more automation and AI to filter noise, assist with patching, and support deployment. "The amount of information and signals that are coming in are way overwhelming. People just get desensitized, and that's when bad things really start to occur," he said.®
Categories: News
Bend the beam like Beckham to defeat anti-jamming tech
Wireless jamming attacks are on the rise. Rice University researchers have shown how self-curving radio beams can make a jammer appear to be somewhere it isn't, potentially undermining some anti-jamming defenses. Jamming relies on flooding a wireless receiver with noise that denies service. Some modern receivers identify and block jamming attempts using direction-of-arrival (DoA) estimation technology that pinpoints the jammer's direction and directs an array null that blocks signals emanating in the jammer’s direction. Were a jammer to transmit a self-curving beam, however, it could fool DoA-based anti-jamming defenses by appearing to come from somewhere else entirely, and that's exactly what the Rice researchers demonstrated. Rice electrical and computer engineering professor Edward Knightly and doctoral student Caroline Spindel presented a paper [PDF] last month in which they demonstrated a curving-beam jamming attack that caused "catastrophic bit-error-rate degradation" while also "fool[ing] the receiver's DoA estimator," preventing conventional DoA-based defenses from stopping the interference. Knightly and Spindel have done prior research developing wireless technology that could bend beams around objects to increase signal strength - particularly useful for short-range millimeter wave signals - and found that the same technology could be used to deploy jammers that are far harder to locate. Spindel gave the perfect analogy in a recent Rice press release about the research for understanding how curved beams confuse DoA estimators by considering a soccer ball kick to the head. “Imagine being hit on the right side of your head by a soccer ball - you would naturally look to the right,” Spindel said. “If the ball actually curved through the air, like a David Beckham free kick, then it was kicked from somewhere else entirely.” Were Sir David to keep moving and kicking curveballs at your head you’d probably spot him eventually, but it might take a minute, and a few more smacks, to stop him. A signal jammer at radio-wave distances will probably be far harder to spot, and it won’t even have to move: Knightly and Spindel were able to create the illusion that the jammer was mobile by modulating the beam parameters from a stationary position, making it even more difficult to locate the jamming signal and negating the point of blindly searching for the best spot to point an array null. Conventional recovery methods used to block jamming completely failed in laboratory tests, Spindel said. “This is the first demonstration of a jammer that cannot be reliably localized and the first time self-curving wireless beams have been used as an attack,” Knightly added. The pair sees their research not just as a way to point out a serious threat to wireless signals - GPS jamming of aircraft is on the rise, for example - but also something that can inform the direction of future wireless technologies as we move toward the 6G era. Until then, however, there’s the potential for even more devastating jamming attacks to come. ®
Categories: News