News

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

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

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

Yet another aggrieved bug hunter has leaked a vulnerability affecting a Microsoft product after becoming disillusioned with the company’s handling of security reports. Ammar Askar dropped a proof of concept (PoC) exploit for a Visual Studio Code (VS Code) flaw within just an hour of disclosing it to “an old contact” at the open source platform, according to his account of things. The vulnerability he exposed involves attackers configuring repos, either of their own making or those they have compromised separately, to push malicious VS Code extensions via its Workspace Recommendations feature, which then steal OAuth tokens they can then use to read/write public and private GitHub repos. It affects anyone who has ever used github.dev, a feature that allows users to open a GitHub repo in a browser-based version of VS Code. Askar said that the feature is enabled by github.com passing an OAuth token over to github.dev and, crucially, this token is not limited to the repo from which github.dev was spun up. It means that this token can hand an attacker access to any other repo – public or private – to which the target also has access. The exploit is contingent on an attacker being able to modify a repo’s .vscode/extensions.json file and recommending an attacker-controlled extension for the browser-based VS Code instance. In normal scenarios, a pop-up would appear asking for a user to accept the installation of this extension, potentially tipping them off to foul play. However, because of the way in which the attacker delivers the repo to the target, they already have a Jupyter Notebook file running in the target’s github.dev before the extension is installed. The attacker must initially get the target to open their repo using a github.dev link that points to this ipynb file, which VS Code immediately opens inside a Webview. Inside the Jupyter Notebook is a hidden HTML snippet inside a Markdown cell, which when loaded allows attacker-controlled JavaScript code to run. This code fires a simulated keyboard shortcut, which VS Code bubbles up to the main editor, tricking the system into automatically accepting the malicious extension popup. The attaker-controlled extension is then running with access to the browser environment, and steals the OAuth token, which can be used to read and change any public or private repo. Askar said past negative experiences with Microsoft Security Response Center (MSRC) influenced his decision not to go through the typical responsible disclosure process, publishing the PoC roughly an hour after tipping off his GitHub contact. “To summarize the last time I interacted with MSRC regarding reporting a VSCode bug, it was a horrible experience where they silently fixed the bug I pointed out without any credit,” he wrote. “They also marked it as not having any security impact. As I mentioned in that post, going forward I would be doing full public disclosure for any security bugs I found in VSCode. Taking a look at a recent report by Starlabs on a VSCode XSS bug marked as ineligible and low severity, it doesn’t look like MSRC has gotten any better about VSCode bugs. “I’m sure the VSCode team would have appreciated a longer heads up on this to come up with solutions. There is legitimately a UI/UX balance here that needs to be struck with the security concerns. To those folks, I am sorry, but this is one of the few levers I have to try to influence MSRC and the security posture of VSCode. Finding and fully developing security bugs into proof-of-concepts like this takes time and effort on the part of security researchers that should not be disrespected or taken for granted.” Askar’s approach is reminiscent of a researcher who goes by Nightmare Eclipse, a suspected former Microsoft employee who has attracted a great deal of attention in recent weeks for leaking zero-days without informing Microsoft beforehand. The researcher has so far released six zero-days, three of which were quickly confirmed to be exploited by attackers in the wild. As regards their motivation for launching this attack on Microsoft, Nightmare Eclipse previously alluded to being stabbed in the back and being left homeless after an agreement that was not honored – all very vague. After the sixth zero-day, Microsoft vaguely threatened the researcher with its Digital Crimes Unit, which works closely with law enforcement, before quickly backing down after an outpouring of negative responses. The Register approached Microsoft for more information. ®