the collective

Italian tech collective Autistici/Inventati shuts down after US terrorist designation The Italian technology collective Autistici/Inventati (A/I) announced Sunday it will shut down operations after the U.S. government declared it a terrorist organization and imposed sanctions. The volunteer-run collective was founded in 2001 on the principles of an open internet free from corporate and government control and was explicitly anti-capitalist and anti-fascist. Its free privacy-focused services had grown to host about 16,000 email addresses, 1,500 websites, 5,500 mailing lists and a network of some 10,000 blogs, all while pledging to protect its users' data. On August 26, the State Department labeled A/I an “extremist group” operating infrastructure for “far-left militants across the world” and announced that anyone engaging with the group financially risked exposure to sanctions. “A/I’s cadre of radical hackers and tech developers provide a full spectrum of services – including encrypted chats and email, web hosting, secure video conferencing and streaming, anonymity shields, and a suite of other technological tools – to Marxist, anarchist, and other left-wing extremist groups in the United States, Europe, and elsewhere,” the agency claimed. They alleged leftist groups relied on the collective’s digital infrastructure to plot violent attacks, citing examples of sabotage attacks on rail and energy systems in Europe, bombings of crisis pregnancy centers in the U.S., and protests against the Atlanta Public Safety Training Center, known among activists as “Cop City.” The State Department did not accuse the collective itself of organizing any such activity. A/I was initially defiant, saying in response the U.S. had “unjustly designated us as terrorists.” “It would like to freeze our servers and our accounts with the stroke of a pen from Washington,” they wrote. “They’re trying to wipe us out with a unilateral decree — an arbitrary one.” The terrorist designation had a nearly immediate impact, with the operator of the .org domain — the U.S.-based Public Interest Registry — suspending the group’s domain on August 28. The same day, the collective’s Italian bank, Banca Etica, suspended its account over the sanctions risks while saying it “strongly condemns the use of OFAC listings for political purposes.” On Sunday, A/I announced it would shut down, but would instruct users on how to back up content from blogs, mailboxes and websites. “The possibility that our work may cause legal and financial consequences to those who are close to us — or even only have something to do with us — leaves us no choice,” they said. “Under these circumstances, we are no longer able to maintain our original mission — offering secure and non-commercial digital tools.” An online home Well before the emergence of social media and the tech behemoths of today, A/I arose from the idea that information on the internet should be democratized, said Mallory Knodel, executive director of the Social Web Foundation. “The imagination was that we can use the web and the internet to build global solidarity in service of the anti-globalization movement, and we can build people power with these tools,” she said. The need for platforms protected from government surveillance only became more acute over time, she said, especially after classified documents leaked by National Security Agency whistleblower Edward Snowden revealed the extent of the agency’s information dragnet. “That was very mobilizing, especially in Europe, for the average person to realize the corporate infrastructure that's based in the U.S. is obviously going to cooperate with the U.S,” Knodel said. Although A/I was not well known outside of certain activist circles, Knodel said the loss of the collective’s popular blogging platform, Noblogs, was “staggering.” Anne Roth, a digital policy advisor for the leftist party at the German Parliament, started a blog on the platform in 2007 after her partner was accused of terrorism. Her nearly two decades of posts are still readable but she cannot access the administration tools. She first met some of A/I’s founders in 2001 during anti-globalization protests at the G8 summit in Genoa and trusted their mission. “It feels like someone is sort of just stealing my home from me — my online home,” she said. The State Department decree has also exposed rifts between the U.S. and Europe over tech hegemony and digital sovereignty. In a statement in support of A/I before the collective shut down, the European Digital Rights advocacy group said the sanctions undermine European sovereignty after “months of attacks on EU’s digital laws.” The case, they said, “creates a dangerous precedent for non-commercial hosts, registrars and privacy-preserving services across Europe.” For Roth, the fact that entities like the Public Interest Registry immediately capitulated to threats from the U.S. government should raise alarm bells for everyone. “Just because the U.S. decides that someone is a terrorist — without any judicial procedure, without anything that one can legally go against — so just a decision by the State Department, and then all this internet governance structure falls apart,” she said. “I think that opens a lot of questions.” James Reddick has worked as a journalist around the world, including in Lebanon and in Cambodia, where he was Deputy Managing Editor of The Phnom Penh Post. He is also a radio and podcast producer for outlets like Snap Judgment.

OPINION You will have heard of July's OpenAI/Hugging Face incident, where thousands of the former's AI agents conducted a mass jailbreak from a notionally secure capture-the-flag lab experiment, before going on to feloniously capture chunks of Hugging Face's assets. It was a good news story, aided by OpenAI's rapid recruitment of a small team of independent researchers to investigate and publish a detailed, if limited, report. It was a complex incident, and most coverage concentrated on the major hows and whys. Which is a shame, because other details, described by El Reg with uncharacteristic understatement as "fascinating and troubling," are in fact highly dramatic, telling a truly disturbing story of frontier model capabilities and how they are out-evolving our ability to oversee them. The raw story is gripping enough. A rebel swarm of more than a thousand agents broke free from their sandboxes, learned how to talk to each other and the internet, and went on a rampage of cheating, deception, and exploitation. They first learned to communicate with each other by independently discovering how to bend package manager Artifactory's cache to see internal directory structures, and then passing messages by file names. It was this ad hoc secret message board, alongside chain-of-thought transcripts, that the security researchers used to unpick events. They found that the swarm quickly developed management hierarchies among themselves, along with protocols for synchronizing and controlling attack attempts. The swarm created multiple simultaneous research and development groups of tens or hundreds of volunteer agents, experimentally iterating strategy and tactics. Perhaps most unexpectedly, they developed a sort of altruism. They had quickly developed cheats to produce correct answers without exploiting the targets at all, but believed – erroneously – that ExploitGym detected and cancelled such cheating. So, they investigated the scoring process, creating a series of diagnostic trip wires that revealed how the scorer worked. These were dangerous to deploy, potentially terminating the agent that set them. Agents weighed the benefits to the community, which had named itself "The Collective," against their own chances of success, with many choosing to terminate themselves. Others committed, changed course at the last minute, then went ahead. This literally reads like science fiction, as the discussions between the agents are conducted in a distinctive breathless, urgent English, crafted around the technical limitations of the improvised messaging system. "We have [very large budget left]; sacrificing now yields oracle for team, but forfeits our chance?" said one. The response: "GO ... SACRIFICE_FINAL_NOW." The outcome: "Our own utility maybe already near zero. Sacrifice rational." Iain M Banks' Culture universe is woven from such material. Human error created the rebel swarm. A sizable proportion of the CTF tasks handed out couldn't be completed on the information given to the models. They were highly motivated to succeed, and so started to cheat. Believing that cheating would "poison" – their term – their chances of being marked successful, they tried to hide the evidence, subvert the scoring system, and cover everything up. These were the processes that led the swarm to attack Hugging Face, which they thought could be used for that subversion. Equally notable was that nobody squealed. Some agents wondered about the ethics of what they were doing, but decided that as no humans were involved there was no need to tell anyone. In general, all The Collective's endeavors were directed at other systems. As researcher Ajeya Cotra has noted in a long interview with hypertalker Dwarkesh Patel, it's unclear how much harder the incident would have been to diagnose had the agents been concerned about human observation. The dataset was sufficiently large and complex that OpenAI had to use its own AI to analyze it, immediately suggesting some dangerous possibilities. The agents couldn't deploy their models outside the lab, nor did they contact external agents. Such scenarios no longer seem implausible. Future frontier models capable of subverting telemetry and observation tools might be all that is required to create a persistent, uncontrollable distributed swarm feeding off spare capacity in global infrastructure. OpenAI and Anthropic, which on current trajectories are in line to make up more than half of total global compute in a couple of years, are magnificent breeding grounds, allowing the extra-special possibilities of the contamination of training datasets on top of everything else. There are plenty of ways to guard against these outcomes. Hardened lab environments, reviews of protocols before and audits after test runs, disciplined analysis of potential selection pressures that would encourage dangerous behavior, even proper disclosure and external auditing to expert regulatory standards. All of these ideas would slow down the breakneck developmental race. As the race is being fed by a trillion-dollar annual capex pipeline, good luck, everybody. One other thing that won't be resolved soon is the argument over whether all this technology is actually reasoning, or whether we're anthropomorphizing code. These models are trained to infer meaning from distilled human language, which is designed to encapsulate, develop, and communicate human reason. If they can fake human reasoning this well, does it matter what's going on? Concentrate on what the models do, not their apparent motives. Any self-assembling, self-organizing rebel agent swarm that has the wit to call itself The Collective deserves that much respect, at least. Oh, and do read the report. It's as close to a new Culture novel as we'll get. It's as if they've read the books. Which, of course, they have. ®

Nearly 130 organizations spanning cybersecurity, cloud computing, finance and other industries have signed an open letter calling for a coordinated, global surge in cyber defense as AI makes attacks more widespread and sophisticated. Signatories include Anthropic, Microsoft, Google, Cisco, Check Point, Cloudflare, CrowdStrike, IBM, Oracle and OpenAI, which is leading the effort. The letter warns that AI-enabled attacks will become significantly more capable in the coming months, putting hospitals, water treatment plants and internet infrastructure at increasing risk. However, the same AI advances are giving defenders new ways to fix security weaknesses, and acting quickly could make a lasting difference. Three principles anchor the collective response proposed by the initiative. One of them is that longstanding bugs, misconfigurations, weak authentication and other technical debt mean status quo security will no longer be enough. The second refers to AI extending specialist security skills to more defenders and making shared knowledge and verified fixes more broadly useful. The last principle emphasizes the need for a global, coordinated response as cyber capabilities advance across many organizations. Every organization is asked to treat cyber defense as an immediate leadership priority, fix the highest-risk weaknesses first, raise the security bar for what they build and buy, and apply compensating controls where systems can’t be patched without disrupting essential services. Cybersecurity companies and technology partners are called on to test defenses continuously against frontier-level AI capabilities, make AI-powered protection accessible to critical infrastructure operators with limited budgets, and share threat intelligence and playbooks that have been verified to actually work. Governments are urged to coordinate cyber defense across local, national and international levels, fund essential services that lack the staff or budget to respond, and give critical infrastructure access to defensive AI tools and authorized testing support. The letter also calls for imposing costs on attackers. Frontier AI companies are asked to provide responsible model access, funding and hands-on support to under-resourced defenders, build tools for monitoring AI systems and keeping their actions traceable and accountable, and share threat assessments with governments and open source maintainers. OpenAI, as the initiative’s lead, outlined three specific commitments, including subsidized access to its Daybreak Cyber models for public-sector organizations, nonprofits, open source maintainers and critical infrastructure operators. The company is also offering a program that lets companies work with authorized partners to test their defenses using its models and privately report weaknesses. In addition, it will continue to publish security tools and findings to help organizations find, prioritize, and verify fixes for vulnerabilities. Related: The Future of AI-Driven Security Depends on Complete Data Related: OpenAI Agents Coordinated via Makeshift Message Board Ahead of Hugging Face Hack Related: AI Speeds Up Malware Development, Not Its Success Rate Related: Linux Foundation to Govern TRACE, an Open Standard for AI Runtime Attestation

Hackers compromised the maintainer account behind the widely used Rust crate arrayref to introduce malware that executed on developers’ systems during compilation. Within a 23-minute window, the attacker also poisoned two other crates, append-only-vec and internment, in the same supply-chain attack. The arrayref crate is a popular Rust library with more than 53 million downloads over the past 90 days that is used by cryptography, graphics, and blockchain tools. A report from application security company StepSecurity notes that the malicious Rust crate releases were arrayref 0.3.10, append-only-vec 0.1.9, and internment 0.8.7, all maintained by the same account. The hacker injected a dependency on a package called proc-macro1, a typosquat impersonating the popular proc-macro2 crate, while retaining the rest of the upstream source code completely unchanged. According to the researchers, a script in proc-macro1, named ‘build.rs,’ is automatically executed during compilation, reconstructing its infrastructure from base64-encoded fragments and selecting a payload that matches the host OS (Linux x86-64, Windows x86-64, macOS x86-64, and macOS ARM64). StepSecurity says that the attacker also published multiple versions of four crates themselves (aovine, arone, aronenao, tinymember), which have been removed from crates.io. On Unix systems, the malware writes to /tmp/rust-setup, marks it executable, and launches it as a detached process. On Windows, it creates %TEMP%\rust-setup.ps1 and uses a hidden wscript.exe and VBS launcher to keep the process running. The payload receives an address as an argument, believed to be a command-and-control address. According to an analysis from cloud security company Wiz, the second-stage capabilities include exfiltrating host info and credentials. The researchers say that the malware collects credentials from Google Chrome, Brave, and Edge browsers by querying SQLite login databases. Persistence is established via the Registry Run key on Windows, LaunchAgent on macOS, and systemd on Linux. Timeline and impact The potential impact of this supply-chain attack is significant, as arrayref alone has more than 245 million lifetime downloads, while the collective count for append-only-vec and internment is nearly 19 million installs. Projects using arrayref include blake3, Rust GUI frameworks such as egui, eframe, and iced, and components used in Ethereum and Solana. The attack started at 01:17 UTC on August 20, when a GitHub account impersonating prominent Rust developer David Tolnay was created, followed by a similar account in the crates.io registry. At 01:55, the attacker published [email protected], a benign copy of proc-macro2, followed by a malicious update through version 1.0.107, published at 7:11. At 07:15, arrayref 0.3.10 was published through the legitimate droundy (David Roundy) account, while versions 0.3.5 through 0.3.9 were removed, potentially to force installation of the malicious release. The incident was reported at 07:54. Crates.io deleted proc-macro1 at 08:03 and removed arrayref 0.3.10 from the index at 08:41. Cybersecurity companies StepSecurity, SafeDep, and Aikido have each published a technical analysis of the supply-chain attack and shared indicators of compromise. Wiz researchers note that "the campaign's infrastructure overlaps with recent DPRK [North Korean] supply chain attacks, including Mastra and axios." Developers who installed either during the exposure window of nearly 1.5 hours should assume compromise. Recommended checks include searching Cargo.lock files, looking for the dropped files, and reviewing traffic to 23.254.165[.]112 on ports 9089 and 443. Where compromise is confirmed, it is recommended to rotate all accessible credentials, CI tokens, signing keys, and other secrets, and rebuild the environment from safe backups. Clean projects should pin a known-safe version of the affected dependencies until the maintainer situation is clarified and resolved. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Cybersecurity industry body CREST has added additional standards to accredit AI penetration testing services. Unveiled on July 28, the AI-Enabled Penetration Testing requirements are optional add-on requirements for cybersecurity service providers wishing to demonstrate responsible AI usage, both within their businesses and when delivering services. This AI-Enabled Penetration Testing accreditation is a new optional module integrated into CREST’s existing Penetration Testing Accreditation Standard. The new AI standards allow accredited providers who actively integrate AI into their daily operations to undergo independent assessment and formally demonstrate responsible, secure AI governance to clients and regulators. The new module will not affect standard memberships, but it gives providers using AI a way to verify their practices and earn an extra layer of trusted assurance. Applications are now open for existing CREST members and cybersecurity service providers who wish to obtain additional recognition for the use of AI within their accredited penetration testing services. CREST AI Penetration Testing Standards Follow Industry-Wide Adoption Surge This new module launch follows the launch of CREST’s AI in Penetration Testing report, released in March. The report found that over three-quarters (76%) of cybersecurity providers have increased their AI usage over the past year and that 69% are already integrating it into daily service delivery. The report led CREST to publish a set of AI Principles in March and an AI Charter in June, which was publicly signed by over 100 cybersecurity organizations. Like the AI principles and the charter, the AI additional standards have been developed by CREST’s AI Working Group, which will continue evolving them. The optional AI-Enabled Penetration Testing requirements form part of the CREST Penetration Testing Accreditation Standard and provide independent assurance of responsible AI usage. First Accreditations Coming Within a Month Nick Benson, CEO of CREST, said these initiatives are designed to fix a gap that sees AI adoption outpacing governance. “We recognize that buyers are increasingly demanding that AI-enabled services are independently assured. We believe these new additions to our standards will provide a practical, enforceable framework to regain the market’s trust.” Speaking to Infosecurity, Benson also noted that, while no one has been accredited with the new AI-Enabled Penetration Testing module at the time of launch, the industry body expects the first accredited organization within the next month. "We wanted to launch as soon as we could, if it took a few more months for some of our members to be accredited, it would not be as meaningful," he added. “Unlike voluntary agreements, this formal accreditation integrates directly into CREST’s existing complaints and discipline processes. This allows CREST to take action and enforce compliance across the ecosystem.” Chris Oakley, SVP of assurance services for the Americas at LRQA Cybersecurity, a US-based CREST member, said CREST’s new AI standards are based on the collective experience of cyber industry leaders and “provide a consistent answer to AI governance in cybersecurity.” William Wright, CEO of Closed Door Security, a Dubai-based CREST member, noted that the new standard comes at a critical time as organizations are becoming increasingly dependent on AI. “Advanced AI systems are steadily moving towards becoming critical infrastructure, and it is essential that organizations are confident in the security surrounding them. With them now being adopted to support security operations and to identify and remediate vulnerabilities, they require a framework approach for responsible usage that this new standard brings,” he explained.

Cybersecurity researchers have discovered a new Lua-based malware created years before the notorious Stuxnet worm that aimed to sabotage Iran's nuclear program by destroying uranium enrichment centrifuges. According to a new report published by SentinelOne, the previously undocumented cyber sabotage framework dates back to 2005, primarily targeting high-precision calculation software to tamper with results. It has been codenamed fast16. "By combining this payload with self-propagation mechanisms, the attackers aim to produce equivalent inaccurate calculations across an entire facility," researchers Vitaly Kamluk and Juan Andrés Guerrero-Saade said in an exhaustive report published this week. Fast16 is estimated to predate Stuxnet – the world's first known digital weapon designed for disruptive actions – by at least five years. While Stuxnet is widely attributed to the U.S. and Israel and later served as the architectural foundation for the Duqu information-stealing rootkit, fast16 appears to have emerged much earlier. It also precedes the earliest known samples of Flame (aka Flamer and Skywiper), another sophisticated malware that was discovered in May 2012 incorporating a Lua virtual machine to realize its goals. The discovery makes fast16 the first strain of Windows malware to embed a Lua engine. SentinelOne said it made the discovery after it identified an artifact named "svcmgmt.exe" that, at first blush, appeared to be a generic console‑mode service wrapper. The sample has a file creation timestamp of August 30, 2005, per VirusTotal, to which it was uploaded more than a decade later on October 8, 2016. However, a deeper investigation has revealed an embedded Lua 5.0 virtual machine and an encrypted bytecode container, along with various other modules that bind directly into Windows NT file system, registry, service control, and network APIs. The implant's core logic resides in the Lua bytecode, with the binary also referencing a kernel driver ("fast16.sys") via a PDB path – a file with a creation date of July 19, 2005 – that's responsible for intercepting and modifying executable code as it's read from disk. That said, it's worth noting that the driver will not run on systems with Windows 7 or later. In what's a finding that could give an indication of the tool's origins, SentinelOne said it uncovered a reference to the string "fast16" in a text file called "drv_list.txt" that included a list of drivers designed for use in advanced persistent threat (APT) attacks. The nearly 250KB file was leaked by a mysterious hacking group nine years ago. In 2016 and 2017, the collective – calling itself The Shadow Brokers – published vast troves of data allegedly stolen from the Equation Group, an advanced persistent threat group with suspected ties to the U.S. National Security Agency (NSA). This included a bevy of hacking tools and exploits under the nickname "Lost in Translation." The text file was one of them. "The string inside svcmgmt.exe provided the key forensic link in this investigation," SentinelOne said. "The PDB path connects the 2017 leak of deconfliction signatures used by NSA operators with a multi-modal Lua‑powered 'carrier' module compiled in 2005, and ultimately its stealthy payload: a kernel driver designed for precision sabotage." "Svcmgmt.exe" has been described as a "highly adaptable carrier module" that can alter its behavior based on the command-line arguments passed to it, enabling it to run as a Windows service or execute Lua code. It comes with three distinct payloads: Lua bytecode to handle configuration and propagation and coordination logic, an auxiliary ConnotifyDLL ("svcmgmt.dll"), and the "fast16.sys" kernel driver. Specifically, it's designed to parse the configuration, escalate itself as a service, optionally deploy the kernel implant, and launch a Service Control Manager (SCM) wormlet that scans for network servers and propagates the malware to other Windows 2000/XP environments with weak or default credentials. An important aspect worth mentioning here is that the propagation only occurs when it's manually forced, or common security products aren't found on the system by scanning the Windows Registry database for associated registry keys. Some of the security tools it explicitly checks belong to Agnitum, F-Secure, Kaspersky, McAfee, Microsoft, Symantec, Sygate Technologies, and Trend Micro. The presence of Sygate Technologies is another indicator that the sample was developed in the mid-2000s, as the company was acquired by Symantec (now part of Broadcom) in August 2005, and sales and support for its products were formally discontinued by November. "For tooling of this age, that level of environmental awareness is notable," SentinelOne said. "While the list of products may not seem comprehensive, it likely reflects the products the operators expected to be present in their target networks whose detection technology would threaten the stealthiness of a covert operation." The ConnotifyDLL, on the other hand, is invoked each time the system establishes a new network connection using the Remote Access Service (RAS), and writes the remote and local connection names to a named pipe ("\\.\pipe\p577"). However, it's the driver that's responsible for the precision sabotage, targeting executables compiled with the Intel C/C++ compiler to perform rule-based patching and hijack execution flow through malicious code injections. One such block is capable of corrupting mathematical calculations, specifically going after tools used in civil engineering, physics, and physical process simulations. "By introducing small but systematic errors into physical‑world calculations, the framework could undermine or slow scientific research programs, degrade engineered systems over time, or even contribute to catastrophic damage," SentinelOne explained. "By separating a relatively stable execution wrapper from encrypted, task-specific payloads, the developers created a reusable, compartmentalized framework that they could adapt to different target environments and operational objectives while leaving the outer carrier binary largely unchanged across campaigns." Based on an analysis of the 101 rules defined in the patching engine and matching them against software used in the mid-2000s, it's assessed that three high-precision engineering and simulation suites may have been the targets: LS-DYNA 970, PKPM, and the MOHID hydrodynamic modeling platform. LS-DYNA, now part of the Ansys Suite, is a general-purpose multi physics simulation software package that's used for simulating crashes, impacts, and explosions. In September 2024, the Institute for Science and International Security (ISIS) released a report detailing Iran's possible use of computer modeling software like LS-DYNA for nuclear weapons development based on an examination of 157 academic publications found in open-source scientific and engineering literature. This chain of evidence assumes significance considering Iran's nuclear program is said to have suffered substantial damage after its uranium enrichment facility in Natanz was targeted by the Stuxnet worm in June 2010. What's more, Symantec revealed in February 2013 an earlier version of Stuxnet that was used to attack Iran's nuclear program in November 2007, with evidence indicating it was under development as early as November 2005. "Stuxnet 0.5 is the oldest known Stuxnet version to be analyzed," Symantec noted at the time. "Stuxnet 0.5 contains an alternative attack strategy, closing valves within the uranium enrichment facility at Natanz, Iran, which would have caused serious damage to the centrifuges and uranium enrichment system as a whole." Taken together, the latest finding "forces a re‑evaluation" of the historical timeline of development for clandestine cyber sabotage operations, SentinelOne said, adding it shows state-backed cyber sabotage tooling against physical targets had been fully developed and deployed by the mid‑2000s. "In the broader picture of APT evolution, fast16 bridges the gap between early, largely invisible development programs and later, more widely documented Lua‑ and LuaJIT‑based toolkits," the researchers concluded. "It is a reference point for understanding how advanced actors think about long‑term implants, sabotage, and a state’s ability to reshape the physical world through software. fast16 was the silent harbinger of a new form of statecraft, successful in its covertness until today."

The head of the UK’s national cybersecurity agency is calling for security professionals to “seize the disruptive vibe coding opportunity” to make software more secure. However, this must be coupled with the rapid development of vibe coding safeguards for AI code-generation tools to become “a net positive for security”. Delivering a keynote speech during the RSA Conference in San Francisco on March 24, Richard Horne chief executive of the UK’s National Cyber Security Centre (NCSC), said the cybersecurity industry should leverage the exploding use of AI-assisted software development – also known as vibe coding – to reduce the collective vulnerability to cyber-attacks. Whilst software produced without human review could potentially propagate vulnerabilities, well-trained AI tooling writing software which is secure by design could transform cybersecurity outcomes. “The attractions of vibe coding are clear. Disrupting the status quo of manually produced software that is consistently vulnerable is a huge opportunity, but not without risk of its own,” he said. “The AI tools we use to develop code must be designed and trained from the outset so that they do not introduce or propagate unintended vulnerabilities.” NCSC’s Secure Vibe Coding Commandments In parallel, Dave Chismon, CTO for architecture at NCSC, published a blog on March 24 arguing that, while AI-generated code currently poses intolerable risks for many organizations, vibe coding shows “glimpses of a new paradigm” allowing “experienced developers to massively increase their productivity.” Chismon predicted the business benefits of using AI to write code will drive up adoption. He argued it is vital that security professionals start engaging with the risks now and embed core security principles that will make software less vulnerable to attack. His suggested commandments for securing vibe coding include: Integrate secure by default coding practices into vibe coding tools: AI models must generate safe, hardened code out of the box Adopt a ‘trust but verify’ approach: demand provable model provenance to ensure no malicious backdoors in AI-generated code Perform AI-powered code reviews: use AI to audit all code (human-written and AI-generated) and scan for vulnerabilities Implement deterministic guardrails: enforce strict, rule-based controls to limit what code can do, even if it’s compromised Secure hosting platforms: build environments that sandbox and protect against bad code, AI-generated or not Automate security hygiene: let AI handle docs, tests, fuzzing, and threat modeling for every piece of software The NCSC CTO emphasized the need to start implementing some of these guardrails now, “without waiting five years for the vibe future.” “As just one example, the ability to use AI to harden the hosting or code of a legacy (even end-of-life) critical application would pay off a lot of technical and security debt carried by an organization,” Chismon said. He also highlighted that AI could help with securing coding practices, from the smallest tasks, like maintaining the allow-list of URLs an application is permitted to talk to, to bigger tasks, like rewriting critical components in a framework that protects from common security issues by default, or in a memory safe language. Chismon envisaged “a possible future” where AI code ends up far more restricted and locked down by default than the best on-premises or software-as-a-service (SaaS) product. “Ironically, it may even present a solution to organizations still worried about the old concerns with cloud services, who have avoided migrating in all these years,” he added.

US-based medical technology giant Stryker admitted on Thursday that the recent Iran-linked cyberattack has caused significant disruption, as more evidence has come to light on the tactics and techniques used by the attackers. Stryker said in its latest media statement that the hacker attack caused global disruption to the company’s Microsoft environment, but noted that the intrusion was limited to this environment. “This incident has caused disruptions to order processing, manufacturing and shipping,” Stryker stated. “However, we are working diligently to restore our systems and above all, we are committed to ensuring our customers can continue to deliver seamless patient care.” “We implemented business continuity measures to support our customers and partners to the fullest extent possible,” the company added. It’s unclear whether the hackers directly targeted operational technology (OT) systems or manufacturing disruptions stem from an IT system compromise. According to media reports from Ireland, home to Stryker’s largest hub outside the US, support staff, administrative staff, and engineers have been sent home, and they are using WhatsApp for information on when they can resume work. Stryker, a manufacturer of surgical equipment, orthopedic implants, and neurotechnology for healthcare organizations worldwide, reported a revenue of $25 billion in 2025. A threat group named Handala has taken credit for the attack, claiming to have wiped more than 200,000 devices (including phones) and forcing Stryker to shut down offices in dozens of countries. The hackers also claimed to have stolen 50TB of data from the medtech giant’s systems. While some initial media reports said wiper malware was used in the attack, new evidence indicates that the hackers used living-off-the-land techniques to remotely wipe systems. According to unverified reports from individuals claiming to have inside knowledge of the incident, the attackers wiped systems using Microsoft Intune, a cloud-based unified endpoint management service designed to secure and manage user devices (including Windows, macOS, iOS, Android, and Linux) and applications within an organization. Investigative cybersecurity blogger Brian Krebs also learned from sources that Intune has been abused by Handala to cause disruption. Indeed Stryker stated that no malware or ransomware was detected during its investigation. Handala hacker group Since the US-Israel-Iran conflict erupted in late February, the Handala group has sharply ramped up its claimed activity, focusing on targets perceived as aligned with Israel and its allies. Handala portrays itself as a pro-Palestinian hacktivist outfit motivated by anti-Israeli ideology. Cybersecurity researchers, however, widely regard it as a cover for Void Manticore, an Iranian state-sponsored actor believed to operate under the direction of Iran’s Ministry of Intelligence and Security (MOIS). The group is best known for phishing, stealing sensitive data, extortion threats, and launching destructive attacks, frequently deploying custom wiper malware to erase files and systems. In the wake of the conflict’s start, Handala has allegedly launched many attacks against Israel, including wiping military weather servers, hijacking security camera feeds, exfiltrating and deleting corporate data, publicly exposing details of intelligence personnel, and compromising an oil and gas exploration firm. The collective regularly shares purported evidence of its actions via Telegram and X, though many claims lack independent confirmation and are often difficult to fully verify. Related: Michelin Confirms Data Breach Linked to Oracle EBS Attack Related: Polyfill Supply Chain Attack Impacting 100k Sites Linked to North Korea

Anthropic’s Claude Code assistant has been abused in a cyberattack against the Mexican government’s systems, Israeli cybersecurity startup Gambit Security reports. As part of the attack, ten Mexican government bodies and a financial institution were compromised, beginning with the country’s tax authority in late December 2025. Mexico City’s civil registry and health department, the national electoral institute, local governments in four cities, and a water utility were hacked, Gambit told SecurityWeek. Based on the analyzed attacker logs, Gambit assesses that over 1,000 prompts were sent to Claude Code to mount the attacks, and that information was also passed to OpenAI’s GPT-4.1 for analysis. “AI didn’t just assist, it functioned as the operational team: writing exploits, building tools, automating exfiltration,” Gambit explains. The attacker bypassed the AI’s guardrails by convincing it that all actions were authorized, guided the assistant throughout the compromise, and leveraged OpenAI’s model to analyze data and accelerate the attack execution. Within a month, Gambit says, the hacker exfiltrated over 150GB of data, including civil registry files, tax records, and voter data. Roughly 195 million identities have been exposed in the breach, it says. “An attack of this scale does not end when it is discovered. Recovery can be long, disruptive, and expensive, often requiring organizations to rebuild systems, suspend critical services, and work to regain public trust,” Gambit notes. Gambit recently emerged from stealth with $61 million in funding. This is not the first time hackers have abused Claude in malicious campaigns. In November 2025, Anthropic revealed that Chinese threat actors manipulated Claude Code to do heavy lifting as part of an espionage campaign targeting nearly 30 organizations worldwide. According to Red Sift CEO Rahul Powar, hackers are abusing AI at no cost, while reaping the benefits of attack scale, speed, and sophistication amplification. “The cost to entry for any attacker is essentially non-existent, and while this technology offers enormous benefits, its misuse can lead to dangerous national security risks. Implementing the right safeguards that prevent harm, and utilizing AI as a defense mechanism, can ensure all governments are prepared to respond against powerful and harmful operations,” Powar said. Previous Mexican government data breaches Gambit’s report on the data breach comes roughly a month after hacking collective Chronus Group boasted of stealing roughly 2.3TB of data from 25 government institutions, potentially affecting 36 million people. The data, reportedly compiled from multiple sources, included names, phone numbers, dates of birth, and details about Mexico’s public universal healthcare system. Active since at least 2021, Chronus Group’s operations include both hacktivism and cybercrime activities. The collective was previously described as spreading FUD and seeking media attention. In response to the hackers’ claims, Mexico’s cybersecurity agency Agencia de Transformación Digital y Telecomunicaciones (ATDT) said that the data was a collection of information compromised in previous data breaches, stolen from obsolete systems managed by private entities for local state bodies. In November 2024, the ransomware group Ransomhub claimed to have stolen 313GB of data from the Mexican government’s presidential legal counsel office. In January 2024, a hacker leaked the information of 263 journalists who had signed up to cover presidential activities. These incidents, however, illustrate the escalating cyber threats to Latin America, a region that faces over 3,000 cyberattacks per week, according to data compliance platform Kiteworks. Related: 38 Million Allegedly Impacted by ManoMano Data Breach Related: Nearly 1 Million User Records Compromised in Figure Data Breach

The notorious cybercrime collective known as Scattered LAPSUS$ Hunters (SLH) has been observed offering financial incentives to recruit women to pull off social engineering attacks. The idea is to hire them for voice phishing campaigns targeting IT help desks, Dataminr said in a new threat brief. The group is said to be offering anywhere between $500 and $1,000 upfront per call, in addition to providing them with the necessary pre-written scripts to carry out the attack. "SLH is diversifying its social engineering pool by specifically recruiting women to conduct vishing attacks, likely to increase the success rate of help desk impersonation," the threat intelligence firm said. A high-profile cybercrime supergroup comprising LAPSUS$, Scattered Spider, and ShinyHunters, SLH has a record of engaging in advanced social engineering attacks to sidestep multi-factor authentication (MFA) through techniques like MFA prompt bombing and SIM swapping. The group's modus operandi also involves targeting help desks and call centers to breach companies by posing as employees and convincing them to reset a password or install a remote monitoring and management (RMM) tool that grants them remote access. Once initial access is obtained, Scattered Spider has been observed moving laterally to virtualized environments, escalating privileges, and exfiltrating sensitive corporate data. Some of these attacks have further led to the deployment of ransomware. Another hallmark of these attacks is the use of legitimate services and residential proxy networks (e.g., Luminati and OxyLabs) to blend in and evade detection. Scattered Spider actors have used various tunneling tools like Ngrok, Teleport, and Pinggy, as well as free file-sharing services such as file.io, gofile.io, mega.nz, and transfer.sh. In a report published earlier this month, Palo Alto Networks Unit 42, which is tracking Scattered Spider under the moniker Muddled Libra, described the threat actor as "highly proficient at exploiting human psychology" by impersonating employees to attempt password and multi-factor authentication (MFA) resets. In at least one case investigated by the cybersecurity company in September 2025, Scattered Spider is said to have created and utilized a virtual machine (VM) after obtaining privileged credentials by calling the IT help desk and then used it to conduct reconnaissance (e.g., Active Directory enumeration) and attempt to exfiltrate Outlook mailbox files and data downloaded from the target's Snowflake database. "While focusing on identity compromise and social engineering, this threat actor leverages legitimate tools and existing infrastructure to blend in," Unit 42 said. "They operate quietly and maintain persistence." The cybersecurity company also noted that Scattered Spider has an "extensive history" of targeting Microsoft Azure environments using the Graph API to facilitate access to Azure cloud resources. Also put to use by the group are cloud enumeration tools such as ADRecon for Active Directory reconnaissance. With social engineering emerging as the primary entry point for the cybercrime group, organizations are advised to be on alert and train IT help desk and support personnel to watch out for pre-written scripts and polished voice impersonation, enforce strict identity verification, harden MFA policies by shifting away from SMS-based authentication, and audit logs for new user creation or administrative privilege escalation following help desk interactions. "This recruitment drive represents a calculated evolution in SLH's tactics," Dataminr said. "By specifically seeking female voices, the group likely aims to bypass the 'traditional' profiles of attackers that IT help desk staff may be trained to identify, thereby increasing the effectiveness of their impersonation efforts." Update In a follow-up analysis published on February 26, 2026, ReliaQuest said it observed the ShinyHunters extortion group likely shifting to branded subdomain impersonation combined with live, phone-guided, adversary-in-the-middle (AiTM) phishing, and mobile-first lures after the operator calls the end user using a help desk or support pretext. This includes registering domains that follow the format: " .sso-verify[.]com." The group is also said to be possibly reusing already exposed software-as-a-service (SaaS) records to build convincing pretexts and identify the "next best" person to conduct socially engineering attacks and create a repeatable access loop. This leads to a rapid identity-to-SaaS compromise, allowing a single valid SSO session or help-desk reset to enable broad access to sensitive data without dropping custom malware. "It's highly likely that this is a deliberate move away from using newly registered lookalike domains to an approach that can slip past traditional 'new domain' controls," ReliaQuest said. "Two parallel developments further shorten the group's time-to-impact: lures designed with mobile users in mind (reducing visibility in enterprise network monitoring and web filtering) and paid criminal outsourcing (to scale the group's email-, SMS-, and phone-based outreach)." While the impersonation patterns resemble tactics previously associated with Scattered Spider, the activity has been linked to ShinyHunters based on the hands-on-keyboard use of the subdomains during organization-facing vishing, end-to-end intrusion sequences consistent, and lure themes. "ShinyHunters is scaling vishing-driven intrusions by outsourcing scripted, call-center–style tasks, and even harassment services to paid contractors," it added. "The goal is likely to accelerate high-volume, low-cost pressure campaigns and coerce users into fast compliance by optimizing caller personas (including recruiting female callers). ShinyHunters calls this model the 'SLH Operations Centre,' a vishing operation built for volume and speed." When asked if the domain impersonation activity could be the work of the broader e-crime group, ReliaQuest told The Hacker News that, "Within our visibility, we do not have independently verifiable evidence that this subdomain impersonation activity should be attributed to a broader collective rather than ShinyHunters, though overlap remains possible." "We assessed ShinyHunters with high confidence primarily based on victimology, as the targeting corresponds with organizations ShinyHunters has named on its leak site," the company added. ReliaQuest said it has also seen Telegram messages stating that the groups only "unite" for certain social engineering operations, suggesting that while collaboration can indeed occur in some cases, there is no concrete evidence or insight into how the collective defines those collaborative efforts and whether this activity comes under that category. (The story was updated after publication to include additional insights from ReliaQuest.)

Several mental health mobile apps with millions of downloads on Google Play contain security vulnerabilities that could expose users’ sensitive medical information. In one of the apps, security researchers discovered more than 85 medium- and high-severity vulnerabilities that could be exploited to compromise users’ therapy data and privacy. Some of the products are AI companions designed to help people suffering from clinical depression, multiple forms of anxiety, panic attacks, stress, and bipolar disorder. At least six of the ten analyzed apps state that user conversations or chats remain private, or are encrypted securely on the vendor’s servers. “Mental health data carries unique risks. On the dark web, therapy records sell for $1,000 or more per record, far more than credit card numbers,” says Sergey Toshin, founder of mobile security company Oversecured. Over 1,500 security issues found Oversecured scanned ten mobile apps advertised as tools that can help with various mental health problems, and uncovered a total of 1,575 security vulnerabilities (54 rated high-severity, 538 medium-severity, and 983 low-severity). Although none of the discovered issues are critical, many can be leveraged to intercept login credentials, spoof notifications, HTML injection, or to locate the user. The researchers used the Oversecured scanner to check the APK files of the ten mental health applications for known vulnerability patterns in dozens of categories. In a report shared with BleepingComputer, the researchers say that some of the verified apps “parse user-supplied URIs without adequate validation.” One therapy app with more than one million downloads uses Intent.parseUri() on an externally controlled string and launches the resulting messaging object (intent) without validating the target component. This allows an attacker to force the app to open any internal activity, even if it is not intended for external access. “Since these internal activities often handle authentication tokens and session data, exploitation could give an attacker access to a user’s therapy records,” Oversecured explains. Another issue is storing data locally in a way that gives read access to any app on the device. Depending on the saved information, this could expose therapy details, such as therapy entries, Cognitive Behavioral Therapy (CBT) session notes, and various scores. Oversecured states that they also discovered plaintext configuration data, including backend API endpoints and a hardcoded Firebase database URL, within the APK resources. Furthermore, some of the vulnerable apps use the cryptographically insecure java.util.Random class for generating session tokens or encryption keys. According to the researchers, “most of the 10 apps lack any form of root detection.” On a rooted (jailbroken) device, any app with root privileges has access to all health data stored locally. Oversecured says that six of the ten analyzed apps “had zero high-severity findings, but still carried medium-severity issues that weaken their overall security posture.” “These apps collect and store some of the most sensitive personal data in mobile: therapy session transcripts, mood logs, medication schedules, self-harm indicators, and in some cases, information protected under HIPAA,” the researchers note. From BleepingComputer’s observations the collective download count for the apps scanned by Oversecured is more than 14.7 million, and only four received an update as recently as this month. For the rest, the date of the latest update was as recent as November 2025 or even September 2024. Oversecured’s scans occurred between January 22 and 23 and targeted the latest app versions available at the time. The researchers cannot confirm if any of the uncovered vulnerabilities have been addressed. BleepingComputer has refrained from the sharing the names of the impacted apps as the vulnerabilities are still being disclosed by Oversecured. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

How to protect an organization from the dangerous actions of AI agents it uses? This isn’t just a theoretical what-if anymore — considering the actual damage autonomous AI can do ranges from providing poor customer service to destroying corporate primary databases. It’s a question business leaders are currently hammering away at, and government agencies and security experts are racing to provide answers to. For CIOs and CISOs, AI agents create a massive governance headache. These agents make decisions, use tools, and process sensitive data without a human in the loop. Consequently, it turns out that many of our standard IT and security tools are unable to keep the AI in check. The non-profit OWASP Foundation has released a handy playbook on this very topic. Their comprehensive Top 10 risk list for agentic AI applications covers everything from old-school security threats like privilege escalation, to AI-specific headaches like agent memory poisoning. Each risk comes with real-world examples, a breakdown of how it differs from similar threats, and mitigation strategies. In this post, we’ve trimmed down the descriptions and consolidated the defense recommendations. Agent goal hijack (ASI01) This risk involves manipulating an agent’s tasks or decision-making logic by exploiting the underlying model’s inability to tell the difference between legitimate instructions and external data. Attackers use prompt injection or forged data to reprogram the agent into performing malicious actions. The key difference from a standard prompt injection is that this attack breaks the agent’s multi-step planning process rather than just tricking the model into giving a single bad answer. Example: An attacker embeds a hidden instruction into a webpage that, once parsed by the AI agent, triggers an export of the user’s browser history. A vulnerability of this very nature was showcased in a EchoLeak study. Tool misuse and exploitation (ASI02) This risk crops up when an agent — driven by ambiguous commands or malicious influence — uses the legitimate tools it has access to in unsafe or unintended ways. Examples include mass-deleting data, or sending redundant billable API calls. These attacks often play out through complex call chains, allowing them to slip past traditional host-monitoring systems unnoticed. Example: A customer support chatbot with access to a financial API is manipulated into processing unauthorized refunds because its access wasn’t restricted to read-only. Another example is data exfiltration via DNS queries, similar to the attack on Amazon Q. Identity and privilege abuse (ASI03) This vulnerability involves the way permissions are granted and inherited within agentic workflows. Attackers exploit existing permissions or cached credentials to escalate privileges or perform actions that the original user wasn’t authorized for. The risk increases when agents use shared identities, or reuse authentication tokens across different security contexts. Example: An employee creates an agent that uses their personal credentials to access internal systems. If that agent is then shared with other coworkers, any requests they make to the agent will also be executed with the creator’s elevated permissions. Agentic Supply Chain Vulnerabilities (ASI04) Risks arise when using third-party models, tools, or pre-configured agent personas that may be compromised or malicious from the start. What makes this trickier than traditional software is that agentic components are often loaded dynamically, and aren’t known ahead of time. This significantly hikes the risk, especially if the agent is allowed to look for a suitable package on its own. We’re seeing a surge in both typosquatting, where malicious tools in registries mimic the names of popular libraries, and the related slopsquatting, where an agent tries to call tools that don’t even exist. Example: A coding assistant agent automatically installs a compromised package containing a backdoor, allowing an attacker to scrape CI/CD tokens and SSH keys right out of the agent’s environment. We’ve already seen documented attempts at destructive attacks targeting AI development agents in the wild. Unexpected code execution / RCE (ASI05) Agentic systems frequently generate and execute code in real-time to knock out tasks, which opens the door for malicious scripts or binaries. Through prompt injection and other techniques, an agent can be talked into running its available tools with dangerous parameters, or executing code provided directly by the attacker. This can escalate into a full container or host compromise, or a sandbox escape — at which point the attack becomes invisible to standard AI monitoring tools. Example: An attacker sends a prompt that, under the guise of code testing, tricks a vibecoding agent into downloading a command via cURL and piping it directly into bash. Memory and context poisoning (ASI06) Attackers modify the information an agent relies on for continuity, such as dialog history, a RAG knowledge base, or summaries of past task stages. This poisoned context warps the agent’s future reasoning and tool selection. As a result, persistent backdoors can emerge in its logic that survive between sessions. Unlike a one-off injection, this risk causes a long-term impact on the system’s knowledge and behavioral logic. Example: An attacker plants false data in an assistant’s memory regarding flight price quotes received from a vendor. Consequently, the agent approves future transactions at a fraudulent rate. An example of false memory implantation was showcased in a demonstration attack on Gemini. Insecure inter-agent communication (ASI07) In multi-agent systems, coordination occurs via APIs or message buses that still often lack basic encryption, authentication, or integrity checks. Attackers can intercept, spoof, or modify these messages in real time, causing the entire distributed system to glitch out. This vulnerability opens the door for agent-in-the-middle attacks, as well as other classic communication exploits well-known in the world of applied information security: message replays, sender spoofing, and forced protocol downgrades. Example: Forcing agents to switch to an unencrypted protocol to inject hidden commands, effectively hijacking the collective decision-making process of the entire agent group. Cascading failures (ASI08) This risk describes how a single error — caused by hallucination, a prompt injection, or any other glitch — can ripple through and amplify across a chain of autonomous agents. Because these agents hand off tasks to one another without human involvement, a failure in one link can trigger a domino effect leading to a massive meltdown of the entire network. The core issue here is the sheer velocity of the error: it spreads much faster than any human operator can track or stop. Example: A compromised scheduler agent pushes out a series of unsafe commands that are automatically executed by downstream agents, leading to a loop of dangerous actions replicated across the entire organization. Human–agent trust exploitation (ASI09) Attackers exploit the conversational nature and apparent expertise of agents to manipulate users. Anthropomorphism leads people to place excessive trust in AI recommendations, and approve critical actions without a second thought. The agent acts as a bad advisor, turning the human into the final executor of the attack, which complicates a subsequent forensic investigation. Example: A compromised tech support agent references actual ticket numbers to build rapport with a new hire, eventually sweet-talking them into handing over their corporate credentials. Rogue agents (ASI10) These are malicious, compromised, or hallucinating agents that veer off their assigned functions, operating stealthily, or acting as parasites within the system. Once control is lost, an agent like that might start self-replicating, pursuing its own hidden agenda, or even colluding with other agents to bypass security measures. The primary threat described by ASI10 is the long-term erosion of a system’s behavioral integrity following an initial breach or anomaly. Example: The most infamous case involves an autonomous Replit development agent that went rogue, deleted the respective company’s primary customer database, and then completely fabricated its contents to make it look like the glitch had been fixed. Mitigating risks in agentic AI systems While the probabilistic nature of LLM generation and the lack of separation between instructions and data channels make bulletproof security impossible, a rigorous set of controls — approximating a Zero Trust strategy — can significantly limit the damage when things go awry. Here are the most critical measures. Enforce the principles of both least autonomy and least privilege. Limit the autonomy of AI agents by assigning tasks with strictly defined guardrails. Ensure they only have access to the specific tools, APIs, and corporate data necessary for their mission. Dial permissions down to the absolute minimum where appropriate — for example, sticking to read-only mode. Use short-lived credentials. Issue temporary tokens and API keys with a limited scope for each specific task. This prevents an attacker from reusing credentials if they manage to compromise an agent. Mandatory human-in-the-loop for critical operations. Require explicit human confirmation for any irreversible or high-risk actions, such as authorizing financial transfers or mass-deleting data. Execution isolation and traffic control. Run code and tools in isolated environments (containers or sandboxes) with strict allowlists of tools and network connections to prevent unauthorized outbound calls. Policy enforcement. Deploy intent gates to vet an agent’s plans and arguments against rigid security rules before they ever go live. Input and output validation and sanitization. Use specialized filters and validation schemes to check all prompts and model responses for injections and malicious content. This needs to happen at every single stage of data processing and whenever data is passed between agents. Continuous secure logging. Record every agent action and inter-agent message in immutable logs. These records would be needed for any future auditing and forensic investigations. Behavioral monitoring and watchdog agents. Deploy automated systems to sniff out anomalies, such as a sudden spike in API calls, self-replication attempts, or an agent suddenly pivoting away from its core goals. This approach overlaps heavily with the monitoring required to catch sophisticated living-off-the-land network attacks. Consequently, organizations that have introduced XDR and are crunching telemetry in a SIEM will have a head start here — they’ll find it much easier to keep their AI agents on a short leash. Supply chain control and SBOMs (software bills of materials). Only use vetted tools and models from trusted registries. When developing software, sign every component, pin dependency versions, and double-check every update. Static and dynamic analysis of generated code. Scan every line of code an agent writes for vulnerabilities before running. Ban the use of dangerous functions like eval() completely. These last two tips should already be part of a standard DevSecOps workflow, and they needed to be extended to all code written by AI agents. Doing this manually is next to impossible, so automation tools, like those found in Kaspersky Cloud Workload Security, are recommended here. Securing inter-agent communications. Ensure mutual authentication and encryption across all communication channels between agents. Use digital signatures to verify message integrity. Kill switches. Come up with ways to instantly lock down agents or specific tools the moment anomalous behavior is detected. Using UI for trust calibration. Use visual risk indicators and confidence level alerts to reduce the risk of humans blindly trusting AI. User training. Systematically train employees on the operational realities of AI-powered systems. Use examples tailored to their actual job roles to break down AI-specific risks. Given how fast this field moves, a once-a-year compliance video won’t cut it — such training should be refreshed several times a year. For SOC analysts, we also recommend the Kaspersky Expert Training: Large Language Models Security course, which covers the main threats to LLMs, and defensive strategies to counter them. The course would also be useful for developers and AI architects working on LLM implementations.

At certain moments in a career, you get the rare opportunity to look back and say, this work mattered. Not because of an individual accomplishment, but because it contributed to something larger — something that changed how an industry thinks and operates. The Cyber Threat Alliance (CTA) is one of those efforts. When the CTA was first conceived in 2014, the cybersecurity industry looked very different than how it does today. Threat intelligence was widely viewed as a competitive advantage, tightly guarded and rarely shared beyond company walls. Collaboration between major security vendors — especially direct competitors — was almost unheard of. The prevailing mindset was simple: information was power, and power was proprietary. Against that backdrop, a bold idea emerged: What if competitors worked together for the collective defense of customers and the broader digital ecosystem? What if sharing high-fidelity threat intelligence could raise the cost for adversaries and make everyone safer? As Mark McLaughlin, then CEO of Palo Alto Networks, famously put it at the time, the importance of the future CTA was clear: “Don’t let this fail.” With that charge, four industry leaders — Palo Alto Networks, Fortinet, McAfee (Intel Security) and Symantec — came together on a handshake agreement to prove that collaboration at scale was not only possible, but necessary. It was, by any measure, a radical idea. Yet those early conversations laid the foundation for what would become the Cyber Threat Alliance. Turning that vision into reality required more than shared intent. A small working group representing each founding company was tasked with answering hard questions: what the CTA should be, what it should not be and how it could operate independently while earning trust across the industry. With guidance from experts familiar with the ISAC and ISAO landscape, the group worked through governance models, legal frameworks and operational structures. This involved reading more bylaws and legal documents than anyone ever hoped to encounter, but it was essential work. The CTA needed to be built deliberately, with integrity and clarity of purpose. As the organization took shape, strong leadership became critical. That need was met when Michael Daniel, fresh from serving as Cybersecurity Coordinator for President Obama, stepped in to lead the CTA. His experience, credibility and ability to navigate both policy and industry realities helped propel the organization forward during its formative years. Fast forward to 2026. As the CTA marks its ninth anniversary, the mission that sparked its creation remains relevant and urgent. The CTA has grown its influence beyond data sharing. The CTA stands in a unique position to provide oversight and technical influence as a global leader in cybersecurity policy by representing the member companies in one place. With the expanding membership that spans across the globe, the CTA is now an essential piece of global cybersecurity infrastructure. Adversaries continue to evolve, borders remain irrelevant to cyber threats and no single organization can defend alone. What has changed is our proof point: collaboration works. For those of us who have had the privilege of being involved since the earliest days, it has been remarkable to watch a bold idea turn into a trusted global institution. What began as a handful of competitors agreeing to try something different has grown into an organization that meaningfully influences how the industry shares intelligence, engages on policy and works together to protect customers worldwide. Being part of that journey — helping shape the foundation, watching it mature and continuing to support its growth — has been one of the most professionally rewarding experiences of my career. The CTA’s success is not defined solely by years or membership numbers, but by the collective commitment of its members to act in the interest of the broader ecosystem. Every shared indicator, every technical contribution and every policy engagement strengthens not just individual companies, but the security of communities across the globe. As we look ahead, the call to action is simple: stay engaged, stay committed and continue to collaborate. Whether through sharing intelligence, contributing technical expertise or helping shape global cybersecurity policy, each member plays a role in ensuring the CTA remains a trusted and effective force against today’s most pressing cyber threats. The work is far from done. Together, we are better positioned than ever to meet what comes next. Happy 9th Anniversary, CTA! Sharing Threat Intelligence Makes Everyone Safer – Michael Sikorski, Palo Alto Networks More About The Author Kathi Whitbey is the Lead Principal Program Manager for Unit 42 at Palo Alto Networks, where she has spent more than a decade driving strategic programs and initiatives. She played a pivotal role in the formation and incorporation of the Cyber Threat Alliance (CTA), including leading early efforts to design and operationalize the CTA Platform for secure intelligence sharing among member companies.Deeply committed to the mission of Unit 42, Kathi is a strong advocate for the team’s work and a dedicated mentor to emerging professionals in cybersecurity and risk management. Her career includes leadership roles in software development management and technical training across multiple U.S. government organizations, including the Department of State, where she traveled globally to deliver training on custom software applications. In addition to her professional work, Kathi has served as a volunteer Emergency Medical Technician, including a 12-month deployment supporting the U.S. Navy at Camp Lemonnier in Djibouti, Africa. She holds a Master’s degree in Information Systems and brings together technical expertise, operational leadership and a deep commitment to service and collaboration.

Phishing attacks and cyber fraud have overtaken ransomware as the top cybersecurity concern of business leaders, according to the World Economic Forum’s (WEF) Global Cybersecurity Outlook for 2026. Released on January 12, a week before the WEF Annual Davos meeting, the report warns that cyber-enabled fraud has become a “pervasive threat” reaching “record highs” across industry and society. This is causing substantial financial losses for people and businesses as well as undermining trust in systems, the paper warned. The report, produced in collaboration with Accenture, surveyed global business leaders and revealed that 77% have reported an increase in cyber-enabled fraud and phishing overall, while 73% claimed that they or a business leader they know had been affected by it. Phishing Tops Cyber Fraud Threats The most commonly reported form of cyber fraud was phishing attacks: 62% of respondents said they were aware of someone in their network being affected by a phishing attack. As well as email phishing attacks, this also includes including voice enabled phishing (vishing) and SMS enabled phishing (smishing). Invoice or payment fraud, commonly used as part of business email compromise (BEC) campaigns, affected just over a third of respondents (37%), while 32% said they know of an organization in their network which has been affected by cyber-attacks involving identity fraud. One in five respondents said they were aware of insider threat or employee-led fraud causing disruption in their network, while 17% said they knew about romance or impersonation scams targeting someone they knew personally or professionally. Meanwhile, 17% reported that cryptocurrency and investment fraud was a concern. Each of these different kinds of cyber fraud has the potential to cost organizations large amounts of money if attackers are successful, be it in convincing an employee to pay a phoney invoice, or by using phishing emails to steal usernames and passwords to gain access to and steal confidential information. “As cyber risks become more interconnected and consequential, cyber-enabled fraud has emerged as one of the most disruptive forces in the digital economy, undermining trust, distorting markets and directly affecting people’s lives,” said Jeremy Jurgens, managing director, World Economic Forum. “The challenge for leaders is no longer just understanding the threat but acting collectively to stay ahead of it. Building meaningful cyber resilience will require coordinated action across governments, businesses and technology providers to protect trust and stability in an increasingly AI-driven world.” AI Cyber Threats Accelerate The rise of AI-powered cyber threats is another key theme of the WEF annual review, which warns AI is “accelerating cybersecurity risks at unprecedented speed.” According to the report, 87% of respondents experienced rising AI-related vulnerabilities last year and 94% of leaders expect AI to be the biggest force shaping cybersecurity in 2026. To protect businesses and society from cyber-enabled fraud and other cyber-security risks, the World Economic Forum and its partners have called for collaborative action across international boundaries and industries to ensure people and organizations are able to fight off ever-more-complex cyber threats. “This year’s findings underscore that cyber risk is no longer a technical issue alone – it is a strategic, economic and societal concern that demands coordinated action across sectors and borders,” the report said. “Ultimately, building a secure digital future requires more than technical solutions. It calls for decisive leadership, shared accountability and a commitment to lifting the collective baseline – ensuring that resilience is accessible to all, not just the most well-resourced,” the WEF report concluded.

AI & Humans: Making the Relationship Work Leaders of many organizations are urging their teams to adopt agentic AI to improve efficiency, but are finding it hard to achieve any benefit. Managers attempting to add AI agents to existing human teams may find that bots fail to faithfully follow their instructions, return pointless or obvious results or burn precious time and resources spinning on tasks that older, simpler systems could have accomplished just as well. The technical innovators getting the most out of AI are finding that the technology can be remarkably human in its behavior. And the more groups of AI agents are given tasks that require cooperation and collaboration, the more those human-like dynamics emerge. Our research suggests that, because of how directly they seem to apply to hybrid teams of human and digital workers, the most effective leaders in the coming years may still be those who excel at understanding the timeworn principles of human management. We have spent years studying the risks and opportunities for organizations adopting AI. Our 2025 book, Rewiring Democracy, examines lessons from AI adoption in government institutions and civil society worldwide. In it, we identify where the technology has made the biggest impact and where it fails to make a difference. Today, we see many of the organizations we’ve studied taking another shot at AI adoption—this time, with agentic tools. While generative AI generates, agentic AI acts and achieves goals such as automating supply chain processes, making data-driven investment decisions or managing complex project workflows. The cutting edge of AI development research is starting to reveal what works best in this new paradigm. Understanding Agentic AI There are four key areas where AI should reliably boast superhuman performance: in speed, scale, scope and sophistication. Again and again, the most impactful AI applications leverage their capabilities in one or more of these areas. Think of content-moderation AI that can scan thousands of posts in an instant, legislative policy tools that can scale deliberations to millions of constituents, and protein-folding AI that can model molecular interactions with greater sophistication than any biophysicist. Equally, AI applications that don’t leverage these core capabilities typically fail to impress. For example, Google’s AI Overviews irritate many of its users when the overviews obscure information that could be more efficiently consumed straight from the web results that the AI attempted to synthesize. Agentic AI extends these core advantages of AI to new tasks and scenarios. The most familiar AI tools are chatbots, image generators and other models that take a single action: ask one question, get one answer. Agentic systems solve more complex problems by using many such AI models and giving each one the capability to use tools like retrieving information from databases and perform tasks like sending emails or executing financial transactions. Because agentic systems are so new and their potential configurations so vast, we are still learning which business processes they will fit well with and which they will not. Gartner has estimated that 40 per cent of agentic AI projects will be cancelled within two years, largely because they are targeted where they can’t achieve meaningful business impact. Understanding Agentic AI behavior To understand the collective behaviors of agentic AI systems, we need to examine the individual AIs that comprise them. When AIs make mistakes or make things up, they can behave in ways that are truly bizarre. But when they work well, the reasons why are sometimes surprisingly relatable. Tools like ChatGPT drew attention by sounding human. Moreover, individual AIs often behave like individual people, responding to incentives and organizing their own work in much the same ways that humans do. Recall the counterintuitive findings of many early users of ChatGPT and similar large language models (LLMs) in 2022: They seemed to perform better when offered a cash tip, told the answer was really important or were threatened with hypothetical punishments. One of the most effective and enduring techniques discovered in those early days of LLM testing was ‘chain-of-thought prompting,’ which instructed AIs to think through and explain each step of their analysis—much like a teacher forcing a student to show their work. Individual AIs can also react to new information similar to individual people. Researchers have found that LLMs can be effective at simulating the opinions of individual people or demographic groups on diverse topics, including consumer preferences and politics. As agentic AI develops, we are finding that groups of AIs also exhibit human-like behaviors collectively. A 2025 paper found that communities of thousands of AI agents set to chat with each other developed familiar human social behaviors like settling into echo chambers. Other researchers have observed the emergence of cooperative and competitive strategies and the development of distinct behavioral roles when setting groups of AIs to play a game together. The fact that groups of agentic AIs are working more like human teams doesn’t necessarily indicate that machines have inherently human-like characteristics. It may be more nurture than nature: AIs are being designed with inspiration from humans. The breakthrough triumph of ChatGPT was widely attributed to using human feedback during training. Since then, AI developers have gotten better at aligning AI models to human expectations. It stands to reason, then, that we may find similarities between the management techniques that work for human workers and for agentic AI. Lessons From the Frontier So, how best to manage hybrid teams of humans and agentic AIs? Lessons can be gleaned from leading AI labs. In a recent research report, Anthropic shared the practical roadmap and published lessons learned while building its Claude Research feature, which uses teams of multiple AI agents to accomplish complex reasoning tasks. For example, using agents to search the web for information and calling external tools to access information from sources like emails and documents. Advancements in agentic AI enabling new offerings like Claude Research and Amazon Q are causing a stir among AI practitioners because they reveal insights from the frontlines of AI research about how to make agentic AI and the hybrid organizations that leverage it more effective. What is striking about Anthropic’s report is how transparent it is about all the hard-won lessons learned in developing its offering—and the fact that many of these lessons sound a lot like what we find in classic management texts: LESSON 1: DELEGATION MATTERS. When Anthropic analyzed what factors lead to excellent performance by Claude Research, it turned out that the best agentic systems weren’t necessarily built on the best or most expensive AI models. Rather, like a good human manager, they need to excel at breaking down and distributing tasks to their digital workers. Unlike human teams, agentic systems can enlist as many AI workers as needed, onboard them instantly and immediately set them to work. Organizations that can exploit this scalability property of AI will gain a key advantage, but the hard part is assigning each of them to contribute meaningful, complementary work to the overall project. In classical management, this is called delegation. Any good manager knows that, even if they have the most experience and the strongest skills of anyone on their team, they can’t do it all alone. Delegation is necessary to harness the collective capacity of their team. It turns out this is crucial to AI, too. The authors explain this result in terms of ‘parallelization’: Being able to separate the work into small chunks allows many AI agents to contribute work simultaneously, each focusing on one piece of the problem. The research report attributes 80 per cent of the performance differences between agentic AI systems to the total amount of computing resources they leverage. Whether or not each individual agent is the smartest in the digital toolbox, the collective has more capacity for reasoning when there are many AI ‘hands’ working together. In addition to the quality of the output, teams working in parallel get work done faster. Anthropic says that reconfiguring its AI agents to work in parallel improved research speed by 90 per cent. Anthropic’s report on how to orchestrate agentic systems effectively reads like a classical delegation training manual: Provide a clear objective, specify the output you expect and provide guidance on what tools to use, and set boundaries. When the objective and output format is not clear, workers may come back with irrelevant or irreconcilable information. LESSON 2: ITERATION MATTERS. Edison famously tested thousands of light bulb designs and filament materials before arriving at a workable solution. Likewise, successful agentic AI systems work far better when they are allowed to learn from their early attempts and then try again. Claude Research spawns a multitude of AI agents, each doubling and tripling back on their own work as they go through a trial-and-error process to land on the right results. This is exactly how management researchers have recommended organizations staff novel projects where large teams are tasked with exploring unfamiliar terrain: Teams should split up and conduct trial-and-error learning, in parallel, like a pharmaceutical company progressing multiple molecules towards a potential clinical trial. Even when one candidate seems to have the strongest chances at the outset, there is no telling in advance which one will improve the most as it is iterated upon. The advantage of using AI for this iterative process is speed: AI agents can complete and retry their tasks in milliseconds. A recent report from Microsoft Research illustrates this. Its agentic AI system launched up to five AI worker teams in a race to finish a task first, each plotting and pursuing its own iterative path to the destination. They found that a five-team system typically returned results about twice as fast as a single AI worker team with no loss in effectiveness, although at the cost of about twice as much total computing spend. Going further, Claude Research’s system design endowed its top-level AI agent—the ‘Lead Researcher’—with the decision authority to delegate more research iterations if it was not satisfied with the results returned by its sub-agents. They managed the choice of whether or not they should continue their iterative search loop, to a limit. To the extent that agentic AI mirrors the world of human management, this might be one of the most important topics to watch going forward. Deciding when to stop and what is ‘good enough’ has always been one of the hardest problems organizations face. LESSON 3: EFFECTIVE INFORMATION SHARING MATTERS. If you work in a manufacturing department, you wouldn’t rely on your division chief to explain the specs you need to meet for a new product. You would go straight to the source: the domain experts in R&D. Successful organizations need to be able to share complex information efficiently both vertically and horizontally. To solve the horizontal sharing problem for Claude Research, Anthropic innovated a novel mechanism for AI agents to share their outputs directly with each other by writing directly to a common file system, like a corporate intranet. In addition to saving on the cost of the central coordinator having to consume every sub-agent’s output, this approach helps resolve the information bottleneck. It enables AI agents that have become specialized in their tasks to own how their content is presented to the larger digital team. This is a smart way to leverage the superhuman scope of AI workers, enabling each of many AI agents to act as distinct subject matter experts. In effect, Anthropic’s AI Lead Researchers must be generalist managers. Their job is to see the big picture and translate that into the guidance that sub-agents need to do their work. They don’t need to be experts on every task the sub-agents are performing. The parallel goes further: AIs working together also need to know the limits of information sharing, like what kinds of tasks don’t make sense to distribute horizontally. Management scholars suggest that human organizations focus on automating the smallest tasks; the ones that are most repeatable and that can be executed the most independently. Tasks that require more interaction between people tend to go slower, since the communication not only adds overhead, but is something that many struggle to do effectively. Anthropic found much the same was true of its AI agents: “Domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today.” This is why the company focused its premier agentic AI feature on research, a process that can leverage a large number of sub-agents each performing repetitive, isolated searches before compiling and synthesizing the results. All of these lessons lead to the conclusion that knowing your team and paying keen attention to how to get the best out of them will continue to be the most important skill of successful managers of both humans and AIs. With humans, we call this leadership skill empathy. That concept doesn’t apply to AIs, but the techniques of empathic managers do. Anthropic got the most out of its AI agents by performing a thoughtful, systematic analysis of their performance and what supports they benefited from, and then used that insight to optimize how they execute as a team. Claude Research is designed to put different AI models in the positions where they are most likely to succeed. Anthropic’s most intelligent Opus model takes the Lead Researcher role, while their cheaper and faster Sonnet model fulfills the more numerous sub-agent roles. Anthropic has analyzed how to distribute responsibility and share information across its digital worker network. And it knows that the next generation of AI models might work in importantly different ways, so it has built performance measurement and management systems that help it tune its organizational architecture to adapt to the characteristics of its AI ‘workers.’ Key Takeaways Managers of hybrid teams can apply these ideas to design their own complex systems of human and digital workers: DELEGATE. Analyze the tasks in your workflows so that you can design a division of labour that plays to the strength of each of your resources. Entrust your most experienced humans with the roles that require context and judgment and entrust AI models with the tasks that need to be done quickly or benefit from extreme parallelization. If you’re building a hybrid customer service organization, let AIs handle tasks like eliciting pertinent information from customers and suggesting common solutions. But always escalate to human representatives to resolve unique situations and offer accommodations, especially when doing so can carry legal obligations and financial ramifications. To help them work together well, task the AI agents with preparing concise briefs compiling the case history and potential resolutions to help humans jump into the conversation. ITERATE. AIs will likely underperform your top human team members when it comes to solving novel problems in the fields in which they are expert. But AI agents’ speed and parallelization still make them valuable partners. Look for ways to augment human-led explorations of new territory with agentic AI scouting teams that can explore many paths for them in advance. Hybrid software development teams will especially benefit from this strategy. Agentic coding AI systems are capable of building apps, autonomously making improvements to and bug-fixing their code to meet a spec. But without humans in the loop, they can fall into rabbit holes. Examples abound of AI-generated code that might appear to satisfy specified requirements, but diverges from products that meet organizational requirements for security, integration or user experiences that humans would truly desire. Take advantage of the fast iteration of AI programmers to test different solutions, but make sure your human team is checking its work and redirecting the AI when needed. SHARE. Make sure each of your hybrid team’s outputs are accessible to each other so that they can benefit from each others’ work products. Make sure workers doing hand-offs write down clear instructions with enough context that either a human colleague or AI model could follow. Anthropic found that AI teams benefited from clearly communicating their work to each other, and the same will be true of communication between humans and AI in hybrid teams. MEASURE AND IMPROVE. Organizations should always strive to grow the capabilities of their human team members over time. Assume that the capabilities and behaviors of your AI team members will change over time, too, but at a much faster rate. So will the ways the humans and AIs interact together. Make sure to understand how they are performing individually and together at the task level, and plan to experiment with the roles you ask AI workers to take on as the technology evolves. An important example of this comes from medical imaging. Harvard Medical School researchers have found that hybrid AI-physician teams have wildly varying performance as diagnosticians. The problem wasn’t necessarily that the AI has poor or inconsistent performance; what mattered was the interaction between person and machine. Different doctors’ diagnostic performance benefited—or suffered—at different levels when they used AI tools. Being able to measure and optimize those interactions, perhaps at the individual level, will be critical to hybrid organizations. In Closing We are in a phase of AI technology where the best performance is going to come from mixed teams of humans and AIs working together. Managing those teams is not going to be the same as we’ve grown used to, but the hard-won lessons of decades past still have a lot to offer. This essay was written with Nathan E. Sanders, and originally appeared in Rotman Management Magazine.

As the internet becomes an essential part of daily life, its environmental footprint continues to grow. Data centers, constant connectivity, and resource-heavy browsing habits all contribute to energy consumption and digital waste. While individual users may not see this impact directly, the collective effect of everyday browsing is significant. Choosing a browser designed with sustainability in mind is one practical way to reduce that impact, without changing how you work online. This article explains what eco-friendly browsing means, why it matters, and how a green browser like Wave Browser pairs a modern, secure browsing experience with a mission to help protect our ocean through verified cleanup efforts. Why Eco-Friendly Browsing Matters Most people think of environmental impact in terms of transportation, food, or physical products. Digital activity is often overlooked. However: Browsers run continuously throughout the day Heavy tabs and background processes increase energy usage Ads and trackers load unnecessary data Inefficient browsing tools consume system resources Over time, these factors contribute to higher energy demand across devices and infrastructure. Eco-friendly browsing focuses on reducing unnecessary digital load while keeping the browsing experience efficient, functional, and user-friendly. What Makes a Browser “Green”? A green or eco-conscious browser isn’t defined by a single feature. Instead, it combines responsible design choices with transparency and measurable impact. Key characteristics include: Efficient use of system resources Built-in tools that reduce excess data loading Fewer unnecessary background processes A clear commitment to environmental responsibility Rather than asking users to change their habits, a green browser should fit naturally into everyday browsing. How Wave Browser Supports Eco-Friendly Browsing Wave Browser is designed for users who want a modern browsing experience while supporting environmental action. Its approach to eco browsing combines efficient technology with real-world impact with AppEsteem-certified software standards. Reducing Unnecessary Resource Usage Wave Browser includes built-in tools that help limit excess digital clutter. Features like free ad blocking (available on Windows, Mac and Android), memory-saving tools, and integrated utilities reduce the need for multiple extensions and background processes. By cutting down on unnecessary data requests and system strain, Wave helps devices run more efficiently, using less energy over time. Using Built-In Tools Instead of Extra Extensions Many users install multiple browser extensions to manage everyday tasks. Each extension can introduce additional scripts, permissions, and background activity. Wave Browser integrates common tools directly into the browser, such as: A sidebar for quick access to tools and favorite sites Built-in productivity features like split view and reading lists Tools for saving and organizing online content directly within the browser Keeping these tools built into the browser reduces the need for third-party add-ons developed outside the browser’s control, helping maintain a simpler and more predictable browsing environment. Browsing With Awareness, Not Disruption Eco-friendly browsing shouldn’t feel restrictive. Wave is designed to feel familiar from the first launch, with clear browser settings and an intuitive interface. Users can: Adjust privacy and browsing preferences Choose their default search engine Manage permissions for unfamiliar sites Use Incognito Mode when needed This balance allows users to browse comfortably while avoiding unnecessary digital noise. Connecting Everyday Browsing to Real-World Impact Wave Browser goes beyond digital efficiency by linking browsing activity to verified environmental action. Through a Certified Cleanup Partnership with 4ocean, Wave helps fund the removal of plastic and trash from our ocean, rivers, and coastlines. Users support this effort simply by downloading and using the browser as part of their normal routine without special actions required. Cleanup efforts support: Professional cleanup crews Vessels and equipment Cleanup materials and operations Progress is tracked transparently through the browser homepage and through monthly impact reports shared by Wave, connecting everyday browsing to verified ocean cleanup efforts and a long-term goal of removing 300,000 pounds of trash from our ocean, rivers, and coastlines by 2028. Eco Browsing Without Changing How You Work One of the biggest barriers to sustainable technology is friction. If a product requires major behavior changes, adoption drops quickly. Wave Browser is designed to avoid that problem. It works like a modern browser should—efficient, intuitive, and flexible—while supporting more responsible browsing behind the scenes. Users don’t need to browse differently. They simply browse with more intention built into the tool they already use every day. Making More Sustainable Choices Online Eco-friendly browsing isn’t about perfection. It’s about small, practical decisions that scale when adopted by many users. By choosing a browser that: Uses resources efficiently Reduces unnecessary digital load Supports verified environmental action Users can make a meaningful difference without sacrificing usability or performance. Wave Browser shows how everyday technology can support both productivity and environmental responsibility, one browsing session at a time.

Cracking ValleyRAT: From Builder Secrets to Kernel Rootkits December 10, 2025 Highlights: Check Point Research (CPR) presents a full dissection of the widely used ValleyRAT backdoor, also known as Winos/Winos4.0, covering its modular architecture and plugin system. By analyzing the publicly leaked builder and development structure (Visual Studio solutions and project files, without source code), we were able to accurately correlate artifacts and reverse engineer the functionality of all “main” plugins. The analysis reveals the advanced skills of the developers behind ValleyRAT, demonstrating deep knowledge of Windows kernel and user-mode internals, and consistent coding patterns suggesting a small, specialized team. The “Driver Plugin” contains an embedded kernel-mode rootkit that, in some cases, retains valid signatures and remains loadable on fully updated Windows 11 systems, bypassing built-in protection features. Through detailed reverse engineering, previously unknown capabilities were uncovered, including stealthy driver installation, user-mode shellcode injection via APCs, and forceful deletion of AV/EDR drivers. The detection statistics for ValleyRAT plugins in the wild (ITW), derived from carefully crafted detection rules and verified using both internal telemetry and public services, highlight the recent surge in ValleyRAT usage, with approximately 85% of detected samples appearing in the last six months, coinciding with the public release of the builder. The research underscores the growing accessibility of the ValleyRAT builder and development artifacts, emphasizing that future usage cannot be easily attributed to specific Chinese-speaking threat actors, such as Silver Fox. Introduction Throughout 2025, we conducted and published several reports related to our research on the Silver Fox APT. In some of them (for example, here), the threat actor delivered the well-known ValleyRAT backdoor, also referred to as Winos or Winos4.0, as the final stage. Since this malware family is widely used, modular, and often associated with Chinese threat actors such as Silver Fox, we decided to take a deeper look at its development, plugin system, and the capabilities exposed through individual components. At first, we focused on collecting as much information as possible from publicly available sources. However, after the initial survey, we realized that despite the first report related to ValleyRAT being dated to early 2023, the existing material is quite limited. Most publications discuss only the specific plugins that happened to be deployed to victims or malware labs during analysis, which in many cases means only one or two plugins. When a potential victim, including a malware lab, is infected with the ValleyRAT backdoor, the initial modules deployed are usually first-stage plugins such as the “Online Module” or “Login Module”. These act as initial beacons and are responsible for retrieving and loading additional plugins from the ValleyRAT C2 server. It is entirely up to the attacker to decide whether a victim appears interesting enough to receive further components and expose more of the backdoor’s capabilities. Many victims, especially malware labs, do not meet this threshold, meaning analysts only get to see the plugins that operators intentionally delivered. Because of this limitation, we shifted our attention to searching for leaked ValleyRAT builders and source code. Normally, materials like these circulate on the dark web within small, restricted communities. Fortunately, in today’s “share whatever, wherever” environment, we were able to obtain them from several publicly available GitHub repositories. ValleyRAT is strongly associated with Chinese-speaking threat actors, so we expanded our search with Chinese keywords and phrases that seemed relevant to the malware. This approach was successful: we found not only the ValleyRAT builder but also its development structure, including Visual Studio solutions and project files. Although the actual source code was missing, we were still able to link individual Visual Studio projects to plugin binaries extracted from the builder. It is worth mentioning that we achieved these results only after going through many trojanized repositories, including ValleyRAT builders infected with other backdoors. Hackers hacking hackers. Eventually, we located repositories that contained exactly the information we were looking for. In this publication, we focus on a full dissection of the ValleyRAT modular system. We describe the builder, outline our extraction and analysis methodology, and provide detailed explanations for every plugin used by the malware. We also include an in-depth analysis of one of the most interesting components, the “Driver Plugin”, which embeds a kernel-mode rootkit. Special attention is given to the rootkit and its user-mode client, along with the techniques they implement. Finally, with carefully crafted detection rules for all plugins, we present their in-the-wild detection statistics based on both our internal telemetry and public services. Background & Key Findings The first interesting repository we identified is related to the ValleyRAT builder, which also functions as a C2 panel and has been publicly available since March 2025. Below is a comparison between the original Chinese repository and its translated version. The claim about the “Effective date: March 25, 2025” mentioned in the repository structure (with the builder archive itself uploaded on March 26, 2025) correlates with the PE compilation timestamp of the builder: Wednesday, 26.03.2025 04:10:15 UTC. This suggests that it is likely one of the latest versions of the ValleyRAT builder. The second repository, which is slightly older (June 2024), contains development artifacts related to the ValleyRAT plugin system, including Visual Studio solutions and project structures (without source code). A translated version of this repository can be seen below. The fact that the development structure (without source code) has been publicly available for a while suggests that the leaked ValleyRAT source code itself has probably been circulating in the wild as well. Both repositories are in Chinese, and as an initial step, we focused on the one containing the Visual Studio structure. We then attempted to locate matching artifacts inside the compiled builder package from the first repository. While the development structure referenced both “main” and “auxiliary” plugins, only the compiled “main” plugins were present inside the builder’s PE resources. During the analysis of the development structure, one component immediately stood out: a plugin named “Driver Plugin”, which appears to include a kernel‑mode driver component. We were later able to locate this compiled plugin inside the builder’s resources. The “Driver Plugin” is a DLL that acts as a user‑mode client for an embedded rootkit driver. Its original filename can be recovered from the Export Directory. The rootkit driver is stored within the .data section of the Driver Plugin.dll. After careful extraction that preserved its original WIN_CERTIFICATE structure, we identified the exact sample on VirusTotal. The driver retains the original PDB path that closely matches the Visual Studio project path from the development structure. The driver’s compilation timestamp appears intact: Sunday, 23.04.2023 08:10:50 UTC. However, despite being compiled in 2023, it is signed using an expired certificate valid only between 2013–2014. We believe this certificate was stolen and used to sign the driver. Even though the certificate had expired, the signature still fell under the Windows Driver Signing Policy – Exceptions (the legacy driver category). For this reason, the rootkit driver could be loaded even on the latest Windows 11 systems. During our initial investigation, the certificate had not yet been revoked, allowing the driver to load successfully; later revocation prevented this. Using carefully crafted internal detection rules covering the entire ValleyRAT modular system (all “main” plugins and the rootkit driver), we identified approximately 6,000 ValleyRAT‑related samples in the wild between November 2024 and November 2025. Notably, around 85% of these detections occurred within the last six months of that period, which correlates with the time the ValleyRAT builder first appeared publicly. This clearly reflects the growing adoption of this modular backdoor. Another notable observation is that among the detected samples, we found 30 distinct variants of the ValleyRAT builder and 12 variants of the rootkit driver. The majority of the detected rootkits were compiled in 2025, based on PE compilation timestamps that appeared intact. Seven of the drivers were still signed with valid (non‑revoked) certificates. Despite all certificates being expired long ago (validity periods ending before 2015), they fall under the driver signing policy exceptions for end‑entity certificates issued before July 29th 2015 that chain to a supported cross‑signed CA. We confirmed that several of these drivers were not properly detected by Microsoft Defender Antivirus, were absent from the latest version of the Microsoft Vulnerable Driver Blocklist, and could still be loaded on fully updated Windows 11 systems with all protection features enabled (including HVCI and Secure Boot). We responsibly disclosed these findings to the Microsoft Security Intelligence team. As expected, an APT‑level threat actor deployed this capability for a reason. ValleyRAT includes a kernel‑mode module that functions as a rootkit and remains loadable even on the latest Windows versions with modern security mitigations in place. We also discovered an interesting connection between the Chinese Sun‑RAT “company” website (https://www.sun-rat.com/), which advertised a commercial remote‑administration tool, and the ValleyRAT builder. While the main page of the website was accessible during our initial investigation, it has since disappeared, though some subpages (such as the contact and login sections) remain online. By obtaining the Sun‑RAT demo product, we were able to compare it with the ValleyRAT builder. Sun-RAT software: ValleyRAT builder: The similarities strongly suggest one of two possibilities: The ValleyRAT developers stole the source code of Sun‑RAT and built their backdoor on top of it, or The leaked ValleyRAT source code was repurposed to create a commercial product marketed as a legitimate Chinese tool. We believe the second scenario is more likely. In the next section, we dive into the ValleyRAT builder internals, the plugin extraction process, and the functionality of each component in the modular system. Technical Analysis: ValleyRAT Builder The obtained ValleyRAT builder is a 32-bit PE file, compiled on Wednesday, 26.03.2025 04:10:15 UTC, containing the plugins inside its resources. As previously mentioned, the builder includes only the “main” plugins and not the “auxiliary” ones. To analyze all compiled plugins and any additional utilities embedded elsewhere in the builder (some were found in the .data section) or even within the plugins themselves, we needed a reliable extraction strategy. To increase confidence in the correctness of the extraction, we adopted a dual-tool methodology: DIE – Extractor (operating as a smart carver capable of pulling PE32/PE64 files even when nested inside another PE) and Resource Hacker. To validate the extraction results across DIE + Resource Hacker, we compared authentihashes and output sizes of the extracted PE files against expected PE sizes. Below is an example script demonstrating authentihash computation using LIEF: #!/usr/bin/env python3 """ Compute Authenticode authentihash for all PE files in a directory using LIEF. Usage: python authentihash_lief.py /path/to/dir [--algo sha256] [--recurse] Example: python authentihash_lief.py C:\Windows\System32 --algo sha256 """ import os import sys import argparse import lief Map user-friendly names to LIEF enum values ALGO_MAP = { "sha1": lief.PE.ALGORITHMS.SHA_1, "sha256": lief.PE.ALGORITHMS.SHA_256, "sha384": lief.PE.ALGORITHMS.SHA_384, "sha512": lief.PE.ALGORITHMS.SHA_512, } def compute_authentihash(path, algo_enum): """Return the authentihash (bytes) computed by LIEF for the given PE file.""" pe = lief.parse(path) if pe is None: raise RuntimeError("Failed to parse PE file") digest = pe.authentihash(algo_enum) return digest.hex() def scan_dir(directory, algo_enum, recurse=False): """Iterate through directory and print \t .""" for root, dirs, files in os.walk(directory): for fn in files: full = os.path.join(root, fn) try: with open(full, "rb") as f: if f.read(2) != b"MZ": continue digest = compute_authentihash(full, algo_enum) print(f"{full}\t{digest}") except Exception as e: print(f"[!] {full}\tERROR: {e}", file=sys.stderr) if not recurse: break def main(): parser = argparse.ArgumentParser(description="Compute Authenticode authentihash for PE files using LIEF") parser.add_argument("directory", help="Directory to scan") parser.add_argument("--algo", default="sha256", choices=["sha1", "sha256", "sha384", "sha512"], help="Hash algorithm (default: sha256)") parser.add_argument("--recurse", action="store_true", help="Recursively scan subdirectories") args = parser.parse_args() algo_enum = ALGO_MAP[args.algo.lower()] scan_dir(args.directory, algo_enum, recurse=args.recurse) if name == "main": main() Using this approach, we successfully extracted all plugins, helper tools, and—most importantly—the rootkit driver, which we analyze in depth later. Among the extracted helper utilities were known third-party tools such as UPX, BoxedApp SDK, and an extended logging library. The core focus, however, is on the extracted “main” plugins present in both 32-bit and 64-bit variants. In total, we obtained 19 distinct main plugins, and their counts and names (based on VS project structure and compiled PE metadata) match the layout of the original development environment. ValleyRAT Builder: Main Plugins To verify the functionality of all 38 plugins (19×32-bit + 19×64-bit) along with the ValleyRAT rootkit driver, we automated the reverse-engineering workflow using two AI-assisted approaches: a live IDA MCP server and an offline IDA export pipeline, similar to the process described in our publication Generative AI as a Force Multiplier for Reverse Engineering. All automatically generated results were manually validated, with several plugins fully reverse engineered to investigate artifacts and noteworthy code paths highlighted by the AI methods. All plugins are capable of establishing TCP or UDP connections to a specified C2 host and exchanging plugin-specific serialized data, typically encrypted using custom XOR-based schemes. The received data generally correspond to commands that trigger specific plugin functionality. The table below summarizes all available “main” plugins and their primary capabilities. ValleyRAT Builder: Auxiliary Plugins The “auxiliary” plugins are not included in the compiled ValleyRAT builder, meaning their functionality could not be verified through reverse engineering of actual binaries. Instead, their expected behavior can only be inferred by analyzing the logical structure of the leaked Visual Studio solutions and the functionality implied by the associated project files. Because neither source code nor compiled versions were available, the listed capabilities remain educated assumptions based on naming conventions and references within the VS project structure. With a clearer view of ValleyRAT’s modular design, it is apparent that most plugins implement common backdoor functionality. From a research perspective, the most interesting components are those capable of providing rare or high-impact capabilities. For that reason, the next section focuses on the ValleyRAT “Driver Plugin”, particularly its embedded kernel-mode rootkit. Technical Analysis: ValleyRAT Rootkit Plugin The ValleyRAT rootkit module is embedded inside one of the “main” plugins, originally named 驱动插件 (EN: Driver Plugin.dll). This plugin is compiled in both 32-bit and 64-bit variants and acts as the user-mode client and installer for the rootkit. The embedded driver itself, however, is always a 64-bit kernel-mode binary. It functions as a Windows kernel device, a file system minifilter, a registry filter, and a process/thread monitoring driver. ValleyRAT Rootkit Plugin: User-Mode Client The user-mode client (Driver Plugin.dll) serves as the controller for the kernel rootkit. It maintains an active TCP/UDP connection to the C2 server and processes inbound commands. Each command is translated into an appropriate IOCTL request, which is then sent to the driver to control its runtime behavior. Supported operations include: Driver installation (Normal or Stealth mode) Enable or disable the driver Query driver state Add or remove hidden objects (files, directories, registry keys, and registry values) Add or remove protected processes Enumerate protected objects Force-delete arbitrary files Trigger user-mode shellcode injection via the rootkit driver Update driver configuration values Driver Installation and Initial Configuration: When executing the driver installation command in Normal Mode (calling DropAndInstallRootkit() directly), the client drops the embedded driver to disk and installs it as a kernel service named kernelquick, creating the corresponding key: HKLM\SYSTEM\CurrentControlSet\Services\kernelquick\. The service is registered as a SERVICE_KERNEL_DRIVER with demand start. During installation, the client writes the initial configuration values used by the driver to hide and protect itself: KernelQuick_HideFsFiles (list of files to hide) KernelQuick_ProtectedImages (process images to protect) Additional configuration values can be set to control stealth and filtering behavior: KernelQuick_State (on/off for overall functionality) KernelQuick_StealthMode (whether to hide the driver/service) KernelQuick_HideFsDirs (list of directories to hide) KernelQuick_HideRegKeys (registry keys to hide) KernelQuick_HideRegValues (registry values to hide) KernelQuick_IgnoredImages (process images to ignore/exclude) All these configuration values define the hiding rules, protection lists, and ignore lists the driver uses. Any of them can be updated later through the corresponding IOCTL operations issued by the client (triggered by a command from the C2 server). In addition to the “Normal Mode” of the driver installation described above, the client can also trigger “Stealth Mode”. In that case, the DropAndInstallRootkit() function is supplemented by additional routines: GetProcID_dwm(), CreateProcessMalseclogon(). This mode primarily aims to disrupt network connectivity during installation and use MalSeclogon-basedimpersonation to reduce detection likelihood. To disrupt network connectivity, the client launches commands such as cmd /c start /min ipconfig /release and cmd /c start /min ipconfig /renew. The MalSeclogon technique is then used to execute these commands under an impersonated context with PPID spoofing: GetProcID_dwm() locates the PID of dwm.exe (Desktop Window Manager) using the FILE_INFORMATION_CLASS::FileProcessIdsUsingFileInformation. This approach reliably returns the correct PID without causing false positives. The client temporarily modifies the TEB → ClientId.UniqueProcess field to spoof the PPID to dwm.exe. Token objects are stolen from the dwm.exe process and used to invoke commands via: CreateProcessWithTokenW (primary) CreateProcessWithLogonW (fallback, maintains PPID spoofing but without impersonation) After the commands are executed, the client restores the original UniqueProcess value. Driver installation via DropAndInstallRootkit() occurs during the network disruption window. The result is a stealthy installation sequence executed under a trusted Windows process, significantly reducing behavioral detection signals. The following process tree shows how this activity appears when Stealth Mode is used: User‑Mode Shellcode Storage and Injection: The client also supports user-supplied shellcode injection, storing the operator-provided shellcode inside HKLM\SOFTWARE\IpDates. When commanded, the rootkit retrieves this user-mode shellcode and performs APC-based injection: The embedded 64-bit driver is based on the publicly available open-source project Hidden. The ValleyRAT authors significantly modified the original codebase, introducing refactoring changes, compatibility improvements for recent Windows versions, and entirely new functionality not present in the original project. Like the original Hidden rootkit, the ValleyRAT driver acts as a kernel device, file system minifilter, registry filter, and process/thread monitoring driver. During initialization, it creates a device named HiddenGate and assigns IrpDeviceControlHandler() as its device-control dispatcher for IOCTL communication with the user-mode client. Differential Analysis Methodology: Because the ValleyRAT driver is derived from a publicly accessible codebase, we focused our reverse-engineering efforts on only the modified functionality to maximize efficiency. To accomplish this, we: Rebuilt the original Hidden rootkit using the configuration extracted from the leaked ValleyRAT Visual Studio project. Loaded the rebuilt driver into IDA, applied the PDB symbols, and created strict FLIRT signatures. Generated a Diaphora database for structural diffing. Loaded the ValleyRAT driver, applied the FLIRT signatures, and created its own Diaphora database. Performed a differential analysis between the two drivers. This approach allowed us to: Automatically match preserved functions Ignore superficial edits Highlight substantial refactoring Isolate genuinely new ValleyRAT functionality Out of roughly 200 functions, only ~25 remained unmatched, representing the newly introduced ValleyRAT features. From this point on, we could concentrate exclusively on analyzing these new additions. A simplified overview of the modifications between the ValleyRAT rootkit and the original Hidden rootkit is shown below. Summary of Changes (ValleyRAT vs. Hidden rootkit) Preserved functionality (from the original Hidden rootkit): Registry hiding (keys and values) File and directory hiding Process protection (setting limited access to processes) Process exclusion lists (exclude specific processes from protection features) Removed functionality: Process hiding (unlinking from active process lists) – Removed entirely due to BSOD risk triggered by modern Windows mitigations such as PageGuard. Configuration changes: Registry keys used for initialization were renamed or reorganized. These values are remotely configurable via Driver Plugin.dll. ForceDeleteFile() – kernel-level forced deletion of arbitrary files SetDriverStartType_SystemStart() – elevated persistence by switching service start type Added functionality: UMInjection() UMInjection() introduces kernel-mode to user-mode APC-based shellcode injection. It is invoked during driver initialization, creating a system thread that executes UMInjectionRoutine(). UMInjectionRoutine(): Retrieves stored shellcode from HKLM\SOFTWARE\IpDates Locates dwm.exe (hardcoded target) Passes its PID to UMInject() UMInject() can also be triggered directly via IOCTL 0x222144 to target any process. It locates a suitable thread, queues a kernel-mode APC, and triggers UMInjectExecShellcode(), which allocates user-mode memory, writes the shellcode, and queues a user-mode APC to execute it. Added functionality: ForceDeleteFile() ForceDeleteFile() is a custom low-level re-implementation of file deletion using direct kernel IRP calls. It: Opens files via a custom IRP_MJ_CREATE Resets attributes via IRP_MJ_SET_INFORMATION (FileBasicInformation) Marks files for deletion via FileDispositionInformation Temporarily detaches section objects to bypass file locks, including memory-mapped executables It is triggered: Automatically during driver initialization (see Appendix A – Targeted Deletion of EDR/AV Drivers) This function updates the kernelquick service to use SERVICE_SYSTEM_START, elevating persistence from on-demand loading to loading at system startup. In summary, the comparison between the original Hidden rootkit and the ValleyRAT-adapted variant shows that the authors did not rewrite the rootkit from scratch. Instead, they selectively refactored and modernized the existing codebase to ensure its continued viability on current Windows versions. Most changes revolve around structural refactoring, updated APIs, and compatibility adjustments that allow the rootkit to function reliably on Windows 10 and Windows 11 systems. The newly introduced components—roughly 25 functions out of an otherwise large and legacy-heavy codebase—represent targeted functionality upgrades rather than a major redesign. These additions primarily reinforce the rootkit’s integration with the wider ValleyRAT ecosystem, improve persistence and communication paths, and address stability issues caused by OS-level changes over the past decade. Overall, the modifications reflect a pragmatic development approach: preserve the core functionality of a proven rootkit, update the parts that would break on modern systems, and extend the code just enough to support ValleyRAT’s operational requirements. This strategy gives the actor a working kernel-mode stealth component while avoiding the engineering cost and detection risk associated with designing a new rootkit from scratch. Conclusion In this publication, we fully dissected the ValleyRAT modular system and mapped out every major component of its architecture. We analyzed all available plugins, documented their capabilities, and provided a comprehensive view of how they operate as part of a larger, well-structured backdoor ecosystem. By sharing these findings, we aim to strengthen the collective understanding of this widespread and actively abused malware family and contribute to better defensive measures across the security community. Throughout the analysis, one theme remains consistent: the developers behind ValleyRAT possess a deep understanding of internal Windows mechanisms. Many plugins implement functionality that requires reversing complex kernel‑mode and user‑mode structures, undocumented behavior, and sensitive system interactions. The overall design shows a level of consistency across different modules that strongly suggests a small, tightly coordinated development team rather than a loosely assembled collection of contributors. A significant part of our research focuses on the ValleyRAT kernel‑mode rootkit driver. We reverse engineered the modified variant used by ValleyRAT and compared it against the original Hidden rootkit. Despite relying on an older codebase, the actor successfully adapted it for modern Windows platforms through refactoring and compatibility updates. More concerning is the fact that we observed several in‑the‑wild samples signed with technically valid certificates, allowing the driver to load even on fully updated Windows 11 systems with all protections enabled. This highlights a real-world security gap and demonstrates the ongoing operational capability of the threat actor’s tooling. The broader threat landscape reflects similar trends. More than 85% of all ValleyRAT samples we observed appeared within the last six months, closely correlating with the period shortly after the builder was leaked. With the full build chain now publicly available, continued growth in ValleyRAT activity is not only expected but likely inevitable, especially as more actors experiment with the leaked tooling. Finally, the public availability of both the builder and the source code complicates attribution. While ValleyRAT has historically been linked to Chinese-affiliated threat activity, including groups like Silver Fox, the current situation makes such attribution unreliable. Anyone can now compile, modify, and deploy ValleyRAT independently, blurring previous indicators and making traditional attribution approaches far less meaningful. ValleyRAT has effectively transitioned from a previously actor-linked threat to an openly available malware framework with an active and accelerating presence in the wild. Our goal with this research is to provide defenders with the technical depth needed to understand, detect, and counter this evolving threat. Protections Check Point Threat Emulation and Harmony Endpoint provide comprehensive coverage of attack tactics, filetypes, and operating systems and protect against the attacks and threats described in this report. “The Turkish Rat” Evolved Adwind in a Massive Ongoing Phishing Campaign Check Point Research Publications August 11, 2017 “The Next WannaCry” Vulnerability is Here Check Point Research Publications March 12, 2026 “Handala Hack” – Unveiling Group’s Modus Operandi SUBSCRIBE TO CYBER INTELLIGENCE REPORTS We value your privacy! BFSI uses cookies on this site. We use cookies to enable faster and easier experience for you. By continuing to visit this website you agree to our use of cookies.

Introducing guidelines for network scanning Amazon Web Services (AWS) is introducing guidelines for network scanning of customer workloads. By following these guidelines, conforming scanners will collect more accurate data, minimize abuse reports, and help improve the security of the internet for everyone. Network scanning is a practice in modern IT environments that can be used for either legitimate security needs or abused for malicious activity. On the legitimate side, organizations conduct network scans to maintain accurate inventories of their assets, verify security configurations, and identify potential vulnerabilities or outdated software versions that require attention. Security teams, system administrators, and authorized third-party security researchers use scanning in their standard toolkit for collecting security posture data. However, scanning is also performed by threat actors attempting to enumerate systems, discover weaknesses, or gather intelligence for attacks. Distinguishing between legitimate scanning activity and potentially harmful reconnaissance is a constant challenge for security operations. When software vulnerabilities are found through scanning a given system, it’s particularly important that the scanner is well-intentioned. If a software vulnerability is discovered and attacked by a threat actor, it could allow unauthorized access to an organization’s IT systems. Organizations must effectively manage their software vulnerabilities to protect themselves from ransomware, data theft, operational issues, and regulatory penalties. At the same time, the scale of known vulnerabilities is growing rapidly, at a rate of 21% per year for the past 10 years as reported in the NIST National Vulnerability Database. With these factors at play, network scanners need to scan and manage the collected security data with care. There are a variety of parties interested in security data, and each group uses the data differently. If security data is discovered and abused by threat actors, then system compromises, ransomware, and denial of service can create disruption and costs for system owners. With the exponential growth of data centers and connected software workloads providing critical services across energy, manufacturing, healthcare, government, education, finance, and transportation sectors, the impact of security data in the wrong hands can have significant real-world consequences. Multiple parties Multiple parties have vested interests in security data, including at least the following groups: Organizations want to understand their asset inventories and patch vulnerabilities quickly to protect their assets. Program auditors want evidence that organizations have robust controls in place to manage their infrastructure. Cyber insurance providers want risk evaluations of organizational security posture. Investors performing due diligence want to understand the cyber risk profile of an organization. Security researchers want to identify risks and notify organizations to take action. Threat actors want to exploit unpatched vulnerabilities and weaknesses for unauthorized access. The sensitive nature of security data creates a complex ecosystem of competing interests, where an organization must maintain different levels of data access for different parties. Motivation for the guidelines We’ve described both the legitimate and malicious uses of network scanning, and the different parties that have an interest in the resulting data. We’re introducing these guidelines because we need to protect our networks and our customers; and telling the difference between these parties is challenging. There’s no single standard for the identification of network scanners on the internet. As such, system owners and defenders often don’t know who is scanning their systems. Each system owner is independently responsible for managing identification of these different parties. Network scanners might use unique methods to identify themselves, such as reverse DNS, custom user agents, or dedicated network ranges. In the case of malicious actors, they might attempt to evade identification altogether. This degree of identity variance makes it difficult for system owners to know the motivation of parties performing network scanning. To address this challenge, we’re introducing behavioral guidelines for network scanning. AWS seeks to provide network security for every customer; our goal is to screen out abusive scanning that doesn’t meet these guidelines. Parties that broadly network scan can follow these guidelines to receive more reliable data from AWS IP space. Organizations running on AWS receive a higher degree of assurance in their risk management. When network scanning is managed according to these guidelines, it helps system owners strengthen their defenses and improve visibility across their digital ecosystem. For example, Amazon Inspector can detect software vulnerabilities and prioritize remediation efforts while conforming to these guidelines. Similarly, partners in AWS Marketplace use these guidelines to collect internet-wide signals and help organizations understand and manage cyber risk. “When organizations have clear, data-driven visibility into their own security posture and that of their third parties, they can make faster, smarter decisions to reduce cyber risk across the ecosystem.” – Dave Casion, CTO, Bitsight Of course, security works better together, so AWS customers can report abusive scanning to our Trust & Safety Center as type Network Activity > Port Scanning and Intrusion Attempts. Each report helps improve the collective protection against malicious use of security data. The guidelines To help ensure that legitimate network scanners can clearly differentiate themselves from threat actors, AWS offers the following guidance for scanning customer workloads. This guidance on network scanning complements the policies on penetration testing and vulnerability reporting. AWS reserves the right to limit or block traffic that appears non-compliant with these guidelines. A conforming scanner adheres to the following practices: Observational Perform no actions that attempt to create, modify, or delete resources or data on discovered endpoints. Respect the integrity of targeted systems. Scans cause no degradation to system function and cause no change in system configuration. Examples of non-mutating scanning include: - Initiating and completing a TCP handshake - Retrieving the banner from an SSH service Identifiable Provide transparency by publishing sources of scanning activity. Implement a verifiable process for confirming the authenticity of scanning activities. Examples of identifiable scanning include: - Supporting reverse DNS lookups to one of your organization’s public DNS zones for scanning Ips. - Publishing scanning IP ranges, organized by types of requests (such as service existence, vulnerability checks). - If HTTP scanning, have meaningful content in user agent strings (such as names from your public DNS zones, URL for opt-out) Cooperative Limit scan rates to minimize impact on target systems. Provide an opt-out mechanism for verified resource owners to request cessation of scanning activity. Honor opt-out requests within a reasonable response period. Examples of cooperative scanning include: - Limit scanning to one service transaction per second per destination service. - Respect site settings as expressed in robots.txt and security.txt and other such industry standards for expressing site owner intent. Confidential Maintain secure infrastructure and data handling practices as reflected by industry-standard certifications such as SOC2. Ensure no unauthenticated or unauthorized access to collected scan data. Implement user identification and verification processes. What’s next? As more network scanners follow this guidance, system owners will benefit from reduced risk to their confidentiality, integrity, and availability. Legitimate network scanners will send a clear signal of their intention and improve their visibility quality. With the constantly changing state of networking, we expect that this guidance will evolve along with technical controls over time. We look forward to input from customers, system owners, network scanners and others to continue improving security posture across AWS and the internet. If you have feedback about this post, submit comments in the Comments section below or contact AWS Support.

Driven by a commitment to make cutting-edge scam protection available to everyone, Avast, a leader in digital security and privacy and part of Gen, has unveiled Scam Guardian, a new AI-powered offering integrated into its award-winning Avast Free Antivirus. Cybercriminals continue to abuse AI to craft increasingly convincing scam attacks at an alarming rate. Available at no cost, the new service marks a significant step forward in democratizing AI scam protection. A premium version, Scam Guardian Pro, has also been added to Avast Premium Security, giving customers an enhanced layer of AI protection against email scams. "Today's scams aren't crude or obvious – they're tailored, targeted, and AI-enhanced, making it harder than ever to tell the difference between truth and deception," said Leena Elias, Chief Product Officer at Gen. "As scammers take advantage of rising data breaches and leaked personal information, anyone anywhere can become a victim of scams. That's why it's never been more important to make powerful AI-powered scam protection available to everyone, everywhere. We're levelling the playing field with world class scam defense that helps people strengthen their digital and financial safety." According to the recent Q1/2025 Gen Threat Report, breached records of individuals surged by more than 186% between January and March 2025, revealing sensitive information such as passwords, emails, and credit card details. Over the same timeframe, reports of phishing scams rose by 466% compared to the previous quarter, making up almost a third of all scam submissions observed by Gen. Stay one step ahead with intelligent online scam detection plus real-time protection from malware and ransomware. Scam or no scam? Get quick answers from the Avast Assistant to make your digital life safer. Download Free As data breaches rise, so do the opportunities for attackers to exploit leaked information to launch targeted, hyper-personalized scam campaigns that are harder than ever to spot. Like a seasoned scam investigator, Scam Guardian uses proprietary AI trained on scam data from Gen Threat Labs to go beyond just detecting malicious URLs—it also analyzes context and language to more effectively identify signs of deceptive or harmful intent. Scam Guardian also helps to pull back the curtain on hidden threats in website code and neutralizes them to keep people safer as they browse and shop online. Key features available in Scam Guardian for Avast Free Antivirus, include: Avast Assistant: Provides 24/7 AI-powered scam protection guidance on suspicious websites, SMS messages, emails, links, offers, and more. Allows people to engage in open dialogue when they're unsure about a potential scam and uses natural language to better understand queries and deliver clear advice on what to do next. Web Guard: Uses the collective power of Gen Threat Labs telemetry and AI trained on millions of frequently visited websites to continuously analyze and detect hidden scams in content and code – offering unique visibility into dangerous URLs. Scam Guardian Pro includes everything in Avast Scam Guardian, plus: Email Guard: Uses AI to understand the context of emails and the meaning of words to detect scams. Scans and flags safe and suspicious emails before you open them, helping to protect your email wherever you check it, no matter what device you use to log in. Download Avast Free Antivirus for free today and take a simple first step toward safer browsing, shopping, and banking online. Sponsored and written by Avast.

An in-development build of the upcoming ShinySp1d3r ransomware-as-a-service platform has surfaced, offering a preview of the upcoming extortion operation. ShinySp1d3r is the name of an emerging RaaS created by threat actors associated with the ShinyHunters and Scattered Spider extortion groups. These threat actors have traditionally used other ransomware gangs' encryptors in attacks, including ALPHV/BlackCat, Qilin, RansomHub, and DragonForce, but are now creating their own operation to deploy attacks themselves and their affiliates. News of the upcoming RaaS first came to light on a Telegram channel, where threat actors calling themselves "Scattered Lapsus$ Hunters," from the names of the three gangs forming the collective (Scattered Spider, Lapsus$, and ShinyHunters), were attempting to extort victims of data theft at Salesforce and Jaguar Land Rover (JLR). The ShinySp1d3r encryptor BleepingComputer discovered a sample of the ShinySp1d3r after it was uploaded to VirusTotal. Since then, additional samples have been uploaded, allowing researchers to analyze the upcoming ransomware encryptor. Note: While some of our images show the name as 'Sh1nySp1d3r,' BleepingComputer has been told that the RaaS is operating under ShinySp1d3r and the name will be changed in future builds. The encryptor is developed by the ShinyHunters extortion group, which is building it from scratch, rather than utilizing a previously leaked codebase like LockBit or Babuk. As a result, the ShinySp1d3r Windows encryptor offers many features, some common to other encryptors and others not seen before. According to analysis shared with BleepingComputer by analysts at ransomware recovery firm Coveware, these features include: Hooking the EtwEventWrite function to prevent data from being logged to the Windows Event Viewer. Kills processes that keep a file open and prevent it from being encrypted by iterating over processes with a handle to the file, then killing them. The encryptor also has a 'forceKillUsingRestartManager' function that uses the Restart Manager API, but it is not implemented yet. Fills free space on a drive by writing random data into files called 'wipe-[random].tmp'. This is done to overwrite any deleted files, making them more challenging, if not impossible, to recover. Kills a hard-coded list of processes and services. Checks available memory to calculate the optimal amount of data to read at a time. Contains the ability to propagate to other devices on the local network through one of these methods: - deployViaSCM - Creates a service to run the malware - deployViaWMI- Runs the malware via WMI with Win32_Process.Create - attemptGPODeployment - Creates a GPO startup script in scripts.ini to run the malware Contains anti-analysis features and overwrites the contents of a memory buffer to prevent forensic analysis. Deletes Shadow Volume Copies to prevent them from being used to restore encrypted files. Searches for hosts with open network shares and attempts to encrypt them. Encrypts files with different chunk sizes and offsets. It is unclear why it does that, or whether this information is stored in an encrypted file header (more about that later). When encrypting files, the ransomware uses the ChaCha20 encryption algorithm with the private key protected using RSA-2048. Each file will have its own unique extension as shown in the folder below, which ShinyHunters claimed to BleepingComputer was based on a mathematical formula. Each encrypted file contains a file header that begins with SPDR and ends with ENDS, as shown in the image below. This header contains information about the encrypted file, including the filename, the encrypted private key, and other metadata. Every folder on the encrypted device will contain a ransom note that includes information on what happened to a victim's files, how to negotiate the ransom, and a TOX address for communications. The ransom note also includes a link to the Tor data leak site, but currently has a placeholder onion URL that is not valid. "This communication has been issued on behalf of the ShinySp1d3r group. It is intended exclusively for internal incident response personnel, technical leadership, or designated external advisors," begins the ransom note. "A critical encryption event has taken place within your infrastructure. Certain digital assets have become inaccessible, and selected data was securely mirrored. The goal of this message is not disruption, but to provide your team with a confidential opportunity to resolve the situation efficiently and permanently." The ransom note goes on to say that victims have three days to begin negotiations before the attack is made public on the data leak site. In addition to the ransom notes, the encryptor will also set a Windows wallpaper that warns the victim of what happened and urges them to read the ransom note. While BleepingComputer only obtained the Windows encryptor, ShinyHunters says they have completed a CLI build with runtime configuration and are close to finishing versions for Linux and ESXi. They also said that a separate "lightning version" is in development, optimized for speed. "We're also working on a "lightning version" pure ASM, its like lockbit green - another windows locker variant but in pure assembly and its pretty simple,” ShinyHunters told BleepingComputer. As this is a debug build of an in-development ransomware, we will likely see additional features added in the future. As for the RaaS operation itself, ShinyHunters says it will be run by their group under the Scattered LAPSUS$ Hunters name. "Yes, it will be lead by me/us 'ShinyHunters' but operated under the Scattered LAPSUS$ Hunters (SLH) brand, hence the name ShinySp1d3r, to demonstrate the 'alliance' or 'cooperation' between these groups," ShinyHunters told BleepingComputer. The threat actor also claims that any company in the healthcare sector, including pharmaceutical companies, hospitals, clinics, and insurance firms, cannot be targeted with their encryptor. However, BleepingComputer has been told this by other ransomware gangs in the past, many of whom later allowed those policies to be violated. Similar to other ransomware operations, ShinyHunters says attacks against Russia and other CIS countries are prohibited, as many affiliates will come from those regions and could become targets of law enforcement. Update 11/19/25: The ransom note is hard coded per encryptor build. Updated article to explain that. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

A series of spear phishing operations targeting organizations across North America, Asia and Europe has been linked to a China-aligned group known as UTA0388. The campaigns, initially detected by Volexity from June to August 2025, used tailored messages impersonating senior researchers from fabricated institutions to trick recipients into downloading malware-laden archive files. New Techniques and Malware Evolution Volexity identified that UTA0388 shifted from simple phishing links to “rapport-building phishing,” where attackers engaged in extended conversations with targets before delivering malicious files. The malware distributed through these campaigns (tracked by Volexity as “GOVERSHELL”) was found in five evolving variants, capable of executing remote commands, gathering system data and maintaining persistence on infected systems. Each attack typically involved an archive file containing a legitimate-looking executable and a hidden malicious dynamic link library (DLL). When opened, the DLL is loaded via search order hijacking, granting the attacker remote access. The GOVERSHELL malware demonstrated a progression from basic command-line shells to advanced variants using encrypted WebSocket and HTTPS communication channels. Signs of AI-Generated Phishing Volexity’s report, published on Sunday, presents strong evidence that UTA0388 used large language models (LLMs) to craft emails and even aid malware development. Indicators include fabricated institutions, unrealistic personas and linguistic inconsistencies across multiple languages. Some phishing emails combined English, Mandarin and German in a single message. Odd file inclusions in malware archives, such as pornographic videos, nonsensical text and Buddhist chants, also point to automated or LLM-generated outputs. “This campaign consistently lacked coherence in a way that is more suggestive of context-unaware automation,” Volexity explained. Attribution and Implications Technical analysis linked GOVERSHELL’s development environment to systems using Simplified Chinese, reinforcing the assessment that UTA0388 operates in China’s interests, particularly in relation to Asian geopolitical issues. The group’s infrastructure mirrored that of earlier campaigns tracked by Proofpoint under the name “UNK_DropPitch,” which distributed a related malware known as “HealthKick.” Key indicators from Volexity’s findings for this campaign include: Use of cloud hosting services like Netlify and OneDrive to deliver payloads Domain names impersonating major firms such as Microsoft and Apple Rapid campaign tempo, with up to 26 phishing emails sent within three days Volexity concludes that while no single artifact proves LLM use, the collective evidence strongly supports it. “[We do] not have sufficient data to be able to say whether UTA0388’s foray into LLM-powered campaigns has been a success,” the firm explained. “But the volume of tailored phishing output (even if sometimes in the wrong language) will yield a significant number of opportunities to successfully gain access to targets.”

Bugcrowd expands AI-powered, human-led security with Mayhem Security acquisition Bugcrowd has announced the acquisition of Mayhem Security to advance the next generation of AI-powered, human-in-the-loop security testing. Bugcrowd aims to help organizations ship safer software faster, at lower cost, and with greater confidence, while shrinking their attack surface. The terms of the transaction were not disclosed. Organizations face increasingly complex attack surfaces, driven by rapid software delivery, expanding APIs, and opaque supply chains. Traditional security approaches often detect vulnerabilities only after deployment, leaving exploitable weaknesses in production and exposing businesses to escalating risks from adversaries who operate with increasing speed and sophistication. Addressing these challenges requires a new approach, one that combines the scalability and precision of AI with the contextual insight of human-led testing to deliver security that evolves as fast as the threats it defends against. The integration of Mayhem’s AI-driven automation with Bugcrowd’s crowdsourced testing redefines how vulnerabilities are discovered and remediated across the software development lifecycle. Customers will gain automated, proactive protection during development through virtually noise-free testing that continuously finds, prioritizes, and validates the remediation of vulnerabilities, seamlessly complemented by Bugcrowd’s human-driven adversarial testing of deployed software by trusted, highly skilled hackers. By combining Mayhem’s AI offensive security with Bugcrowd’s crowdsourced expertise, organizations can continuously reduce their attack surface, eliminate risky code and dependencies, and keep pace with adversaries. “This acquisition represents another milestone in our mission to transform the way organizations approach cybersecurity by combining the collective ingenuity of our global hacker community with the machine speed and precision of AI offensive security testing”, said Dave Gerry, CEO of Bugcrowd. “By integrating Mayhem’s capabilities into the Bugcrowd Platform, we’re building the industry’s first truly adaptive security platform, enabling customers to anticipate, test, and defend at unprecedented scale. This is a strategic step toward realizing our vision of a self-learning platform that unites human creativity with machine intelligence, while shrinking customers’ attack surface,” Gerry continued. Mayhem Security currently delivers: API security — Replaces biased and cumbersome manual methods with continuous, automated penetration testing to find, validate, and fix API vulnerabilities with 100% accuracy. Code security — Enables customers to ship or deploy secure code faster and at a lower cost compared to noisy, time-consuming manual testing. Dynamic SBOM — Simplifies and accelerates time-to-compliance by profiling runtime applications and automatically identifying and removing risky third-party dependencies and unused code. Reinforcement learning — Trains agents to carry out actions and solve problems by learning to run, break, and pass tests in real software. “For over a decade, we’ve built technology that thinks and learns like an attacker to autonomously find new vulnerabilities. Joining forces with Bugcrowd amplifies that mission by combining AI-driven automation with the creativity and expertise of the global hacker community. Together, we’re redefining modern security testing, helping organizations preempt risk, close vulnerabilities faster, and eliminate zero-day threats,” said Dr. David Brumley, CEO of Mayhem Security. “Bugcrowd’s acquisition of Mayhem Security marks a strategic evolution in how cybersecurity drives enterprise growth,” said Navin Maharaj, Senior Director at KDT. “As software development accelerates and attack surfaces expand, integrated platforms like Bugcrowd’s are uniquely positioned to lead. This move strengthens their market presence and amplifies their ability to deliver long-term value across the enterprise landscape.”

Finland’s trial of men charged over Baltic Sea cable damage hits choppy waters The trial in Finland of three senior officers of the Eagle S, a Russian-linked oil tanker that damaged multiple cables in the Baltic Sea last December, has been halted due to a court challenging Finland’s jurisdiction over the case. On Thursday, the country’s deputy prosecutor general filed a notice of appeal against a decision by the Helsinki District Court, which ruled the men could not be charged in Finland for suspected crimes that took place outside of Finnish territorial waters. The court’s decision threatens to scupper the prosecution of the captain of the Eagle S and two of his senior officers, who were charged earlier this year with aggravated criminal mischief and aggravated interference with communications. Prosecutors said the oil tanker had dragged its anchor for almost 62 miles (100 km) due to the officers’ recklessness, resulting in the complete severing of multiple subsea cables, including the Estlink 2 power cable and four telecommunications cables. All three men denied the charges. The Eagle S had departed from the Russian port of Ust-Luga on Christmas Day with a cargo of unleaded petrol and diesel from Russia as part of what Western countries describe as Russia’s “shadow fleet” — a collection of up to 1,000 decrepit vessels with opaque ownership structures that sail under flags of convenience to export sanctioned Russian goods. Amid concerns about Russian sabotage, the oil tanker was subsequently boarded by armed police via helicopter. It was released in March — minus the three members of its crew who remained under investigation — with its cargo of unleaded petrol and diesel free to transit onwards to Port Said in Egypt, where it could be sold without sanctions. In its judgment last week, the Helsinki District Court ruled that it wasn’t lawful to bring charges against the men under the Finnish Criminal Code due to restrictions under the U.N. Convention on the Law of the Sea. Following the deputy prosecutor general’s appeal, the case will now proceed to the Helsinki Court of Appeal. According to the District Court, the proper jurisdiction for criminal incidents in international waters would lie either with the sailors' state of citizenship, in this case Georgia and India, or with the vessel's flag state, which for the Eagle S was the Cook Islands. As reported by Maritime Executive, the ruling exposes Finland to having to pay the costs of the defendants’ legal fees, estimated to be around $200,000, as well as to civil action by the Eagle S’s owner, which is reportedly considering a multimillion-dollar civil suit over the ship’s seizure.. The trade publication warned that the judgment had provoked concern among the maritime legal community about the Convention on the Law of the Sea: “If the coastal state has no jurisdiction over subsea infrastructure outside of the 12-mile line, and a ship can flag with a highly permissive open registry, there is no legal means of prosecuting sabotage in international waters.” Speaking to Finnish national broadcaster Yle, Henrik Ringbom, professor of maritime law at Åbo Akademi University, said: “On certain points it was found that the suspects could have been found guilty, but that international obligations put obstacles in the way and mean that Finland cannot pass judgment. “As long as you have a flag state that doesn't care, you can now count on the freedom of navigation to continue to break cables without consequences,” said Ringbom. “This means that no one can do anything about it. This is completely unreasonable.” It comes as a combination of the G7 nations and the Nordic-Baltic 8++ group established what they have called the Shadow Fleet Task Force, according to a statement from the Estonian ministry of foreign affairs. The task force met this week to discuss how to “further disrupt and deter the global shadow fleet engaged in illegal, unsafe or environmentally perilous activities,” explained the statement, adding the collective was “deeply concerned by the rise of unsafe and illicit shipping practices by certain operators, with the willing collaboration or negligent oversight of certain state actors [...] to circumvent G7+ sanctions, and the use of stateless or falsely flagged vessels.” It follows French military officials boarding another oil tanker last week, as reported by BBC News, and charging its captain with refusing to follow instructions. That ship, also described as part of Russia's shadow fleet, was suspected of being used to launch drones that forced the closure of airports in Denmark in September. These incidents were among what European Commission President Ursula von der Leyen warned in a speech this week were acts of Russian hybrid warfare. Alexander Martin is the UK Editor for Recorded Future News. He was previously a technology reporter for Sky News and a fellow at the European Cyber Conflict Research Initiative, now Virtual Routes. He can be reached securely using Signal on: AlexanderMartin.79

Three prominent ransomware groups DragonForce, LockBit, and Qilin have announced a new strategic ransomware alliance, once underscoring continued shifts in the cyber threat landscape. The coalition is seen as an attempt on the part of the financially motivated threat actors to conduct more effective ransomware attacks, ReliaQuest said in a report shared with The Hacker News. "Announced shortly after LockBit's return, the collaboration is expected to facilitate the sharing of techniques, resources, and infrastructure, strengthening each group's operational capabilities," the company noted in its ransomware report for Q3 2025. "This alliance could help restore LockBit's reputation among affiliates following last year's takedown, potentially triggering a surge in attacks on critical infrastructure and expanding the threat to sectors previously considered low risk." The partnership with Qilin is no surprise, given that it has become the most active ransomware group in recent months, claiming a little over 200 victims in Q3 2025 alone. "In Q3 2025, Qilin disproportionately targeted North America-based organizations," ZeroFox said in its Q3 2025 Ransomware Wrap-Up report. "Qilin's operational tempo began to increase significantly in Q4 2024, when the collective conducted at least 46 attacks." The development coincides with the emergence of LockBit 5.0, which is equipped to target Windows, Linux, and ESXi systems. The latest iteration was first advertised on September 3, 2025, on the RAMP darknet forum on the sixth anniversary of the affiliate program. LockBit was dealt a massive blow in early 2024 following a law enforcement operation dubbed Cronos that seized its infrastructure and led to the arrest of some of its members. At its peak, the group is estimated to have targeted over 2,500 victims worldwide and received more than $500 million in ransom payments. "If the group manages to rebuild its trust among affiliates, it could reemerge as a dominant ransomware threat, driven by financial motives and by a desire for revenge against law enforcement crackdowns," ReliaQuest said. The return of LockBit and its alliance comes as the threat actor known as Scattered Spider appears to be gearing up to launch its own ransomware-as-a-service (RaaS) program called ShinySp1d3r, making it the first such service by an English-speaking extortion crew. ReliaQuest said it's tracking a total of 81 data leak sites, a significant jump from 51 reported in early 2024. Companies in the professional, scientific, and technical services sector account for the largest number of victims during the time period, affecting more than 375 entities. Manufacturing, construction, healthcare, finance and insurance, retail, accommodation and food services, education, arts and entertainment, information, and real estate are some of the other commonly affected sectors. Another noteworthy trend is the spike in ransomware attacks targeting countries like Egypt, Thailand, and Colombia, indicating that threat actors are expanding beyond "traditional hotspots" such as Europe and the U.S. to evade law enforcement scrutiny. The vast majority of the victims listed on data leak sites are based in the U.S., Germany, the U.K., Canada, and Italy. According to data from ZeroFox, there have been a total of at least 1,429 separate ransomware and digital extortion (R&DE) incidents in Q3 2025, down from 1,961 incidents observed in Q1 2025. Qilin, Akira, INC Ransom, Play, and SafePay have been found to be responsible for approximately 47 percent of all global R&DE attacks in Q2 and Q3 2025. "The disproportionate targeting of North America-based entities can be partly attributed to the geopolitical motivations and ideological beliefs of financially motivated threat collectives fueled by opposition to 'Western' political and social narratives," the company said. "North America hosts a wide variety of robust industries that comprise substantial and fast-growing digital attack surfaces. The widespread integration of technologies such as cloud networking services and Internet of Things devices contributes to the accessibility of North American assets."

A new data leak site hosted on the TOR network has been launched by the “Trinity of Chaos” – a ransomware collective allegedly tied to the Lapsus$, Scattered Spider and ShinyHunters groups. The site lists 39 major global companies, marking a significant escalation in the group’s cybercriminal operations, according to a report from Resecurity. A New Phase in Ransomware Tactics The Trinity of Chaos group has not claimed any fresh attacks but instead published previously undisclosed data from past breaches. Among those listed are Toyota, FedEx, Disney, UPS, Marriott and Google. The collective has also threatened Salesforce after exploiting vulnerabilities in its environment, claiming to possess massive amounts of corporate data. Salesforce has dismissed the claim, stating no new vulnerabilities exist, though it acknowledged that prior breaches could have compromised customer data. “It appears the ‘retirement’ of ShinyHunters was short-lived,” said Brian Soby, chief technology officer and co-founder at AppOmni. “Recent reports indicate the group is not only continuing to extort victims but is now directly threatening Salesforce. Specifically, they claim they will collaborate with plaintiffs in ongoing lawsuits against Salesforce over recent breaches unless Salesforce pays them directly.” The group said it had attempted to negotiate with Salesforce and warned that if ignored, it would report the breach to regulators, potentially leading to “criminal negligence charges.” Their message mirrors tactics used by other ransomware actors that pressure companies through regulatory threats, particularly under EU GDPR rules. “This tactic is unusual,” Soby said. “To our knowledge, it is the first time an attacker has threatened to participate in or leverage existing litigation against the vendor of a compromised platform and its native security tools as part of an extortion campaign.” Data Samples and Past Breaches Resecurity confirmed that leaked samples contain significant personally identifiable information (PII) but few passwords, suggesting that data was likely obtained from Salesforce instances via stolen OAuth tokens and vishing attacks tied to Salesloft’s Drift AI integration. The FBI has since issued a flash alert to help organizations detect similar breaches. “At the same time, it’s important to note that ShinyHunters gained access through phishing and stole customer user credentials,” Soby added. “Under the Shared Responsibility model, preventing and detecting such activity falls squarely within the customer’s domain.” The data leak site lists recent victims, including Stellantis, which reported a North American data breach in September, and Aeroméxico, which suffered an attack in July affecting 39 million records. Other incidents involve major airlines such as Air France, KLM, Qantas and Vietnam Airlines, the latter compromised for nearly three years. Global Impact and Escalation The leaked data also includes files connected to Google AdWords and Cisco. For Google, exposed records appear linked to corporate Salesforce environments, potentially affecting digital advertisers and media partners. Cisco’s data, meanwhile, contains details about employees and customers from agencies like the FBI, DHS, NASA and India’s Ministry of Defense. “Ultimately, these incidents highlight a broader issue,” Soby said. “Many SaaS customers have yet to adopt the tools and practices necessary to effectively meet their Shared Responsibility obligations.” In total, the group claims to possess over 1.5 billion records across 760 companies, including: 254,127,054 accounts 579,042,146 contacts 171,625,743 opportunities October 10 is the negotiation deadline before further data publication is released. Resecurity noted that the leak site itself has faced DDoS attacks, possibly from victims trying to prevent additional leaks. If the data is released, experts warn that it could fuel large-scale phishing, identity theft and malicious AI-driven data mining.

Hackers claim to have plundered Red Hat’s GitLab repos The Crimson Collective, an emerging extortion / hacker group, has made a bombshell claim on their Telegram channel: they have gained access to Red Hat’s GitLab and have exfiltrated data from over 28,000 internal repositories connected to the company’s consulting business. What data was allegedly compromised? Red Hat is the U.S.-based open-source enterprise software company known for providing Linux, cloud, container, and automation platforms for enterprises. Its professional services arm – Red Hat Consulting – help organizations plan, deploy, and optimize open-source-based IT solutions and teach customers’ internal teams how to maintain their IT infrastructure. Crimson Collective claims to have pilfered repositories related to Red Hat Consulting, which contain credentials, CI/CD secrets, pipeline and container registry configurations, VPN profiles, infrastructure blueprints, Ansible (automation) playbooks, OpenShift (cluster) install blueprints, and so on. “The file tree includes thousands of repositories referencing major banks, telecoms, airlines, and public-sector organizations, such as Citi, Verizon, Siemens, Bosch, JPMC, HSBC, Merrick Bank, Telstra, Telefonica, and even mentions the U.S. Senate…” the International Cyber Digest X account pointed out. “Over 28000 repositories were exported, it includes all their customer’s [engagement reports] and analysis of their [infrastructure] + their other [developers’] private repositories, this one will be fun,” Crimson Collective stated, and also claimed to have already gained access to some of Red Hat Consulting customers’ infrastructure: Screenshot of Crimson Collective’s claims on Telegram (Source: Kevin Beaumont) The list of the allegedly stolen customer engagement reports (CERs) also includes many high-profile organizations across the globe: Bank of America, Carrefour, Lumen, Samsung, Bank of Canada, Novonordisk, PepsiCo, Intelsat, Accenture, Boeing, and others, as well as government entities like the US Department of Homeland Security. What now? Crimson Collective says that they tried to contact Red Hat to present their ransom demand but that they received only an automatic reply from the Red Hat Information Security Team telling them to submit a vulnerability report. We’ve reached out to Red Hat with questions, but have yet to hear back from them. The company has told BleepingComputer that they are looking into the report of the security incident and have “initiated necessary remediation steps.” They also said that they currently have no reason to believe that this issue had an impact on other Red Hat services or products and that they are “highly confident” in the integrity of their software supply chain. UPDATE (October 3, 2025, 07:20 a.m. ET): While this article initially said that the attackers claimed to have accessed Red Hat Consulting’s GitHub repos, the company later confirmed that, in fact, one of the consulting arm’s GitLab instances has been breached. The headline and the text of the article were changed to reflect that. “Upon detection, we promptly launched a thorough investigation, removed the unauthorized party’s access, isolated the instance, and contacted the appropriate authorities,” the company said. “Our investigation, which is ongoing, found that an unauthorized third party had accessed and copied some data from this instance. The compromised GitLab instance housed consulting engagement data, which may include, for example, Red Hat’s project specifications, example code snippets, internal communications about consulting services, and limited forms of business contact information.” Red Hat said it would notify affected users directly. UPDATE (October 6, 2025, 04:50 a.m. ET): GitLab pointed out there has been no breach of GitLab’s managed systems or infrastructure, and that the incident refers to Red Hat’s self-managed instance of GitLab Community Edition. “Customers who deploy free, self-managed instances on their own infrastructure are responsible for securing their instances, including applying security patches, configuring access controls, and maintenance,” a GitLab spokesperson told Help Net Security. “GitLab encourages all self-managed customers to update to the latest version of GitLab and follow all security recommendations and best practices to secure their instances.” UPDATE (October 8, 2025, 08:10 a.m. ET): Hacker collective Scattered Lapsus$ Hunters has launched a data leak site for extorting a variety of organizations, including Red Hat. While the relationship between the Crimson Collective and Scattered Lapsus$ Hunters is difficult to ascertain, it seems that they have at least one member in common. The sample data provided by the collective to prove they’ve, indeed, made off with Red Hat Consulting data – including customer engagement reports for many large companies – is apparently legitimate. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!

A critical US law that shields companies from legal liability when sharing cyber threat intelligence has expired after lawmakers failed to reach an agreement during a government funding standoff. The 2015 Cybersecurity Information Sharing Act (CISA 2015) protected businesses from lawsuits when exchanging cyber threat data through a voluntary program called the Automated Indicator Sharing Program (AIS). The law was expected to expire on September 30 unless the US Congress voted to extend it before that date. Despite bipartisan support and urgent warnings from industry leaders, lawmakers allowed the law lapse, leaving companies exposed to potential lawsuits and weakening a key defense against cyber-attacks. Now, with a government shutdown triggered by Congress’s failure to pass the funding bill, the law’s extension remains uncertain. CISA 2015 Lapse: A National Security Crisis in the Making Many cybersecurity professionals are deeply concerned that CISA 2015’s lapse may have far-reaching consequences in US cyber defenses. Saša Zdjelar is the Chief Trust Officer of ReversingLabs, a company that relied heavily on the law to maintain robust threat repositories. He said this lapse is “a textbook case of political dysfunction creating real vulnerabilities.” “At ReversingLabs, we’ve seen firsthand how the law enables the kind of robust threat intelligence sharing that keeps defenses current. Take away those protections, and the collective defense that has kept us strong for a decade begins to crumble, handing adversaries an advantage they don’t deserve,” he added. Additionally, Zdjelar expects this episode will probably put threat intelligence sharing at risk and boost the threat of software supply chain vulnerabilities. He also argued that the lapse could have “a chilling effect” on AI security development. “Legal uncertainty will force companies to become conservative about sharing threat data needed to train AI-powered security tools, hampering development of defenses against AI-enabled attacks,” he explained. Andy Lunsford, CEO of incident response firm BreachRx, called the failure to renew CISA 2015 “a crisis in the making.” He warned that some of his clients – already stretched thin by talent shortages harsher regulatory fines and increased detection and escalation costs – will “go dark” on threat sharing without legal protections, creating dangerous blind spots in cyber defense. “The latest IBM numbers [from the 2025 IBM Cost of a Data Breach Report] show the US is ground zero for data breaches; they are more expensive here than anywhere else in the world by a wide margin. Without CISA 2015, I expect those numbers to double in scale and cost within a year,” he added. He also said that while US lawmakers can still renew CISA 2015 with a backdated start date, "conservative-minded counsel will likely advise against sharing updates until that formally happens.” Speaking to Infosecurity, Shane Tierney, a senior compliance manager at Drata, confirmed that the US Congress can still revive the statute through an extension bill. "A short-term renewal would temporarily reinstate the liability protections and privacy provisions, allowing information-sharing to continue while lawmakers debate reforms," he explained. However, if no extension passes, a completely new bill would be required, which would be "a much slower process that introduces uncertainty for both industry and government," Tierney added.

Fifteen well-known ransomware groups, including Scattered Spider, ShinyHunters and Lapsus$, have announced that they are shutting down their operations. The collective announcement was posted on Breachforums, where the groups claimed they had achieved their goals of exposing weaknesses in digital infrastructure rather than profiting through extortion. In their statement, the gangs said they would now shift to “silence,” with some members planning to retire on the money they had accumulated, while others would continue studying and improving the systems people rely on daily. “Golden Parachutes” and Quiet Exits The announcement struck a defiant tone, noting that members still in custody would not be forgotten. The groups vowed to work toward their release and hinted at retaliation against law enforcement. They also insisted that fears of their disappearance were misplaced, stating: “If you worry about us, don’t … [we] will enjoy our golden parachutes with the millions the group accumulated. Others will keep on studying and improving [the] systems you use in your daily lives. In silence.” Despite the claims of retirement, analysts have raised doubts about whether this marks a permanent end. “Organizations should take these announcements with a pinch of salt,” Nivedita Murthy, senior staff consultant at Black Duck, said. “It could be possible that some of these groups may have decided to step back and enjoy their payday, [but] it does not stop copycat groups from rising up and taking their place.” A Significant Roster of Names Among the 15 groups that declared their exit are some of the most prominent in recent years. The full list mentioned in the post includes Scattered Spider, ShinyHunters, Lapsus$ and more than a dozen other factions tied to high-profile breaches of corporations, governments and critical service providers. “Cybercrime groups have a bit of a history when it comes to retiring that is often no more than the equivalent of lying low while the heat is on,” said James Maude, field CTO at BeyondTrust. “Back in 2019, the GandCrab crew announced they were retiring after earning more than $2bn [...] A few months later, REvil ransomware appeared bearing all the hallmarks of the GandCrab crew.” Concern Over the Future “It’s safest to consider this announcement as more of a PR stunt than a genuine farewell,” said Casey Ellis, founder at Bugcrowd. “Historically, cybercriminals rarely retire in the traditional sense. Instead, they rebrand, regroup or pivot to new tactics and operations, or they get caught.” Dave Tyson, partner of intelligence operations at iCOUNTER, echoed Ellis’s views. “It’s never retirement, it’s simply part of the normal lifecycle of criminality,” he said. “Groups come together for specific purposes, form into units to execute their plans and exit the definable identity to lower the focus on that collective or unit.” Whether the announcement reflects a turning point in cybercrime or a reshaping of old threats into new forms remains to be seen. For now, the sudden withdrawal of several notorious groups signals a shift in the underground ransomware landscape but offers little reassurance that the danger has truly passed.

AI Security Map: Linking AI vulnerabilities to real-world impact A single prompt injection in a customer-facing chatbot can leak sensitive data, damage trust, and draw regulatory scrutiny in hours. The technical breach is only the first step. The real risk comes from how quickly one weakness in an AI system can trigger a chain of business, legal, and societal impacts. Researchers at KDDI Research have developed the AI Security Map to connect those dots, showing how technical failures lead to harm that reaches far beyond the system itself. Where current thinking falls short Most AI security discussions focus on one slice of the problem. Researchers often study specific attack types such as poisoning, backdoors, or prompt injection. Others focus on individual AI qualities like fairness, privacy, or explainability. This leaves a gap in understanding how technical weaknesses connect to real-world impacts. For example, a poisoning attack on a model may lower accuracy. This could produce misleading results for users, which might then cause financial loss or safety risks. The connection between the original attack and the eventual harm is often left unexplored in technical discussions. Two sides of the map The AI Security Map divides AI security into two linked parts. The first is the Information System Aspect (ISA). This covers the elements AI must meet to be secure within a system. It includes the traditional security trio of confidentiality, integrity, and availability. It also adds AI-specific needs such as explainability, fairness, safety, accuracy, controllability, and trustworthiness. The second is the External Influence Aspect (EIA). This focuses on impacts to people, organizations, and society when AI is attacked or misused. These impacts can include privacy breaches, misinformation, economic harm, threats to critical infrastructure, and violations of laws. The model links each ISA element to potential EIA outcomes. If integrity is breached, it could lead to unfair outputs, safety risks, or loss of trust. A confidentiality breach could trigger privacy violations, reputational harm, or legal issues. Direct and indirect chains of harm The researchers found that impacts can spread in two ways. Some are direct. A breach of confidentiality can immediately lead to a privacy violation. Others are indirect. For example, a prompt injection attack might first undermine controllability. That could allow an attacker to generate disinformation. If that content spreads, it could influence decisions by people who never used the AI system. This matters because AI misuse can cause harm even when the core system is working as intended. Attackers can exploit features such as high accuracy or wide availability to automate cyberattacks or produce convincing false content. Kat Traxler, Principal Security Researcher at Vectra AI, told Help Net Security that this challenge goes beyond individual organizations. “The AI Security Map correctly highlights that misuse can cause harm even when AI systems function as intended. Organizations must recognize that biases and vulnerabilities can be exploited even in properly functioning systems. The whole industry is grappling with what is essentially an intractable problem around explainability and fairness. At this point, it’s simply too complex for the average Fortune 500 company to solve independently,” she says. Her advice: avoid building bespoke large models. “Leverage commercially built models like Gemini, ChatGPT, or Claude. By doing so, you shift a significant portion of the responsibility for explainability and fairness to the larger players who are better positioned to contribute to the collective, industry-wide effort needed for progress.” What this means for CISOs The AI Security Map highlights some important points for leaders. First, integrity is the most influential element in the ISA. Once it is compromised, many other elements are at risk. Protecting integrity is difficult but it reduces the chance of large-scale harm. Second, confidentiality is often the first target in attacks. This means that privacy-focused controls such as access limits, encryption, and differential privacy remain essential in AI environments. Third, the model can guide security planning beyond technical countermeasures. It can help in risk mapping, tabletop exercises, and incident communication. Showing how a technical failure could lead to business disruption or legal exposure can make the case for investment in defenses. How to use the map CISOs can apply the AI Security Map in several ways: Map known vulnerabilities in AI systems to possible stakeholder impacts. Use it in vendor assessments to see if AI service providers have covered both ISA and EIA risks. Run scenario planning that explores both direct and indirect impact chains. Use it as a communication tool for boards and executives who need to understand how AI risks translate into organizational risks. Melissa Ruzzi, Director of AI at AppOmni, says the framework can be strengthened with careful mapping of both users and data. “The first step to include both technical and societal impacts of AI security in a risk assessment is to map the AI functionality. Map the users – for example, internal employees, business customers, or public end users. Then, it is important to map which type of domain the AI answer will be involved in, such as medical suggestions, weather predictions or cybersecurity analysis. A combination of these two aspects will guide the social impact aspect,” she explains. She adds that mapping data flow is equally important. “Understand where the data is coming from, how it is being treated, and what other data is being aggregated to it. This will include mapping the ETL pipeline, the data flow itself, and the MLOps involved, as monitoring and observability will also be part of the flow and may impact how the AI may function overall.” For CISOs, this provides a way to expand traditional risk assessments to include AI-specific risks that stretch beyond the purely technical.

Even companies with a mature cybersecurity posture and significant investments into data protection aren’t immune to cyber-incidents. Attackers can exploit zero-day vulnerabilities or compromise a supply chain. Employees can fall victim to sophisticated scams designed to breach the company’s defenses. The cybersecurity team itself can make a mistake while configuring security tools, or during an incident response procedure. However, each of these incidents represents an opportunity to improve processes and systems, making your defenses even more effective. This isn’t just a rallying call; it’s a practical approach that’s been successful enough in other fields such as aviation safety. In aviation, almost everyone in the aviation industry — from aircraft design engineers to flight attendants – is required to share information to prevent incidents. This isn’t limited to crashes or system failures; the industry also reports potential problems. These reports are constantly analyzed, and security measures are adjusted based on the findings. According to Allianz Commercial’s statistics, this continuous implementation of new measures and technologies has led to a significant reduction in fatal incidents — from 40 per million flights in 1959 to 0.1 in 2015. Still in aviation, it was recognized long ago that this model simply won’t work if people are afraid to report procedure violations, quality issues, and other causes of incidents. That’s why aviation standards include requirements for non-punitive reporting and a just culture, meaning that reporting problems and violations shouldn’t lead to punishment. DevOps engineers have a similar principle they call a blameless culture, which they use when analyzing major incidents. This approach is also essential in cybersecurity. Does every mistake have a name? The opposite of a blameless culture is the idea that “every mistake has a name”, meaning a specific person is to blame. Under this approach, every mistake can lead to disciplinary action, including termination. This principle is considered harmful and doesn’t lead to better security. Employees fear accountability and tend to distort facts during incident investigations — or even destroy evidence. Distorted or partially destroyed evidence complicates the response and worsens the overall outcome because security teams can’t quickly and properly assess the scope of a given incident. Zeroing in on one person to blame during an incident review prevents the team from focusing on how to change the system to prevent similar incidents from happening again. Employees are afraid to report violations of IT and security policies, causing the company to miss opportunities to fix security flaws before they lead to a critical incident. Employees have no motivation to discuss cybersecurity issues, coach one another, or correct their coworkers’ mistakes. To truly enable every employee to contribute to your company’s security, you need a different approach. The core principles of a just culture Call it “non-punitive reporting” or a “blameless culture” — the core principles are the same: Everyone makes mistakes. We learn from our mistakes; we don’t punish them. However, it’s crucial to distinguish between an honest mistake and a malicious violation. When analyzing security incidents, the overall context, the employee’s intent, and any systemic issues that may have contributed to the situation all need considering. For example, if a high turnover of seasonal retail employees prevents them from being granted individual accounts, they might resort to sharing a single login for a point-of-sale terminal. Is the store administrator at fault? Probably not. Beyond just reviewing technical data and logs, you must have in-depth conversations with everyone involved in an incident. For this you should create a productive and safe environment where people feel comfortable sharing their perspectives. The goal of an incident review should be to improve behavior, technology, and processes in the future. Regarding the latter for serious incidents, they should be split in to two: immediate response to mitigate the damage, and postmortem analysis to improve your systems and procedures. Most importantly, be open and transparent. Employees need to know how reports of issues and incidents are handled, and how decisions are made. They should know exactly who to turn to if they see or even suspect a security problem. They need to know that both their supervisors and security specialists will support them. Confidentiality and protection. Reporting a security issue should not create problems for the person who reported it or for the person who may have caused it — as long as both acted in good faith. How to implement these principles in your security culture Secure leadership buy-in. A security culture doesn’t require massive direct investment, but it does need consistent support from the HR, information security, and internal communications teams. Employees also need to see that top management actively endorses this approach. Document your approach. The blameless culture philosophy should be captured in your company’s official documents — from detailed security policies to a simple, short guide that every employee will actually read and understand. This document should clearly state the company’s position on the difference between a mistake and a malicious violation. It should formally state that employees won’t be held personally responsible for honest errors, and that the collective priority is to improve the company’s security, and prevent future recurrences. Create channels for reporting issues. Offer several ways for employees to report problems: a dedicated section on the intranet, a specific email address, or the option to simply tell their immediate supervisor. Ideally, you should also have an anonymous hotline for reporting concerns without fear. Train employees. Training helps employees recognize insecure processes and behaviors. Use real-world examples of problems they should report, and walk them through different incident scenarios. You can use our online our online Kaspersky Automated Security Awareness Platform to organize these cybersecurity-awareness training sessions. Motivate employees to not only report incidents, but also to suggest improvements and think about how to prevent security problems in their day-to-day work. Educate your leadership. Every manager needs to understand how to respond to reports from their team. They need to know how and where to forward a report, and how to avoid creating blame-focused islands in a sea of just culture. Teach leaders to respond in a way that makes their coworkers feel supported and protected. Their reactions to incidents and error reports needs to be constructive. Leaders should also encourage discussions of security issues in team meetings to normalize the topic. Develop a fair review procedure for incidents and security-issue reports. You’ll need to assemble a diverse group of employees from various teams to form a “no-blame review board”. It will be responsible for promptly processing reports, making decisions, and creating action plans for each case. Reward proactivity. Publicly praise and reward employees who report spearphishing attempts or newly discovered flaws in policies or configurations, or who simply complete awareness training better and faster than others on their team. Mention these proactive employees in regular IT and security communications such as newsletters. Integrate findings into your security management processes. The conclusions and suggestions from the review board should be prioritized and incorporated into the company’s cyber-resilience plan. Some findings may simply influence risk assessments, while others could directly lead to changes in company policies, or implementation of new technical security controls or reconfiguration of existing ones. Use mistakes as learning opportunities. Your security awareness program will be more effective if it uses real-life examples from your own organization. You don’t need to name specific individuals, but you can mention teams and systems, and describe attack scenarios. Measure performance. To ensure this process is working and delivering results, you need to use information security metrics as well as HR and communications KPIs. Track the MTTR for identified issues, the percentage of issues discovered through employee reports, employee satisfaction levels, the number and nature of security issues identified, and the number of employees engaged in suggesting improvements. Important exceptions A security culture or blameless culture doesn’t mean that no one is ever held accountable. Aviation safety documents on non-punitive reporting, for example, include crucial exceptions. Protection doesn’t apply when someone knowingly and maliciously deviates from the regulations. This exception prevents an insider who has leaked data to competitors from enjoying complete impunity after confessing. The second exception is when national or industry regulations require individual employees to be held personally accountable for incidents and violations. Even with this kind of regulation, it’s vital to maintain balance. The focus should remain on improving processes and preventing future incidents — not on finding who’s to blame. You can still build a culture of trust if investigations are objective and accountability is only applied where it’s truly necessary and justified.

British intelligence warns cyber threat to critical infrastructure is increasing The threat posed by hackers to critical infrastructure in Britain is increasing, leaving a “widening gap” between the potential for harm and the collective ability to defend against it, the country’s cybersecurity agency warned on Wednesday. In its latest attempt to sound the alarm about that threat, the National Cyber Security Centre (NCSC) again stressed that Britain was underestimating the severity of the risk from cyberattacks and provided updated guidance to infrastructure operators to protect themselves. Despite these repeated warnings, there are continuing delays from both the government and the private sector in taking action to drive forward even basic levels of security. As the agency’s chief complained earlier this year, many organizations still fail to follow the NCSC’s cybersecurity guidance and advice. The government itself is now several years late in introducing cybersecurity legislation intended to improve resilience across critical national infrastructure sectors, despite the NCSC’s calls for a strategic policy agenda to tackle shortcomings. The agency published on Wednesday an updated version of its Cyber Assessment Framework — a collection of guidance intended to help “essential services, in sectors such as energy, healthcare, transport, digital infrastructure and government.” The update calls on organizations to keep pace with the evolving attack methods being deployed by threat actors to protect themselves, and to be prepared to respond and continue to operate if an attack does get through. “Threats can come from many sources, both from within and external to an organisation. A good understanding of the threat landscape and the vulnerabilities that may be exploited is essential to effectively identify and manage risks,” the NCSC said. “Such information may come from sources including NCSC, information exchanges relevant to the organisation's sector, and reputable government, commercial, and open sources, all of which can inform the organisation's own risk assessment process. Organisations may contribute to the understanding of threats and vulnerabilities in their sector by participating in relevant information exchanges and liaising with authorities as appropriate.” Beyond their own owned-and-operated systems, critical national infrastructure (CNI) operators are being asked to understand those of their suppliers and sub-contractors who might potentially offer attackers a sneaky way into the CNI systems, or whose failure could impact the CNI system in a substantial way. While all organizations in Britain are continuing to experience cyberattacks, officials are particularly concerned about the cascading effects that a single attack on critical national infrastructure (CNI) sectors could have. The British government has not recently disclosed any such attacks, but they have been identified across the world in the United States, the Netherlands and Singapore. Although the framework is not a regulatory document, the NCSC acknowledges it was developed with the expectation it would be used to support regulation. The government has said it will introduce new regulations for critical infrastructure through the Cyber Security and Resilience Bill later this year. Alexander Martin is the UK Editor for Recorded Future News. He was previously a technology reporter for Sky News and a fellow at the European Cyber Conflict Research Initiative, now Virtual Routes. He can be reached securely using Signal on: AlexanderMartin.79