Viry a Červi

It's going to be a "messy" summer for security folks, especially when it comes to fixing the open source code that underpins their organizations. That's according to Dan Lorenc, CEO and co-founder of Chainguard, a software supply-chain security company leading Athena, a newly formed coalition of about two dozen companies that wants to make the process of finding and fixing open source bugs "as easy to consume as possible." The members have committed to using AI to prevent attacks on open source software. In addition to Chainguard, other founding member companies include BNY, Cisco, Cloudflare, Corridor, DepthFirst, Docker, JPMorganChase, Kyndryl, LTM, and PwC. Many of these member companies are also partners with Anthropic's Project Glasswing and OpenAI Daybreak, which allow them to try out the pair's most advanced bug-hunting models. The coalition accepts vulnerability findings generated by all frontier models, according to Lorenc. Athena has already processed more than 20,000 findings and developed over 2,000 patches across 500 open source projects. In about three weeks, the coalition's first wave of bug disclosures will begin. "This is going to be a messy summer for everyone," Lorenc told The Register in a phone interview. "I know there's still a percentage of people who think it's all fake and marketing," he said, talking about the newest, most advanced frontier models like Anthropic's Mythos and OpenAI's GPT‑5.5‑Cyber. "The stats and data we're seeing are so scary – if you just keep running scans on the same libraries and same code, it just keeps finding more [vulnerabilities]," Lorenc said. "We haven't seen that curve start to bottom out yet." Chainguard isn't part of Glasswing or Daybreak, but many of its customers and partners are. "Put yourself in the shoes of someone with Glasswing access," he said. "You get this crazy, new model that can find vulnerabilities everywhere, that no one had seen and you had missed for years with all of your other tooling. You run it on your code, and it finds tons of stuff in your first-party code, the stuff that you've written, and you fix all of that." After running Mythos Preview on all of your organization's proprietary code, imagine pointing the model at an application. Most modern apps contain a mixture of code from different sources, mostly third-party. According to Lorenc, 95 percent of the code in any of these codebases is open source. "When you run [advanced models] at the application level, you find a ton of vulnerabilities in open source code that you can't fix for yourself the same way you can that first-party code," Lorenc said. "So then you're left with: what to do?" By now, most people are familiar with vulnerability disclosure processes and know they need to report these flaws to open source project maintainers. "But when the numbers start getting this large, and you're finding thousands of these [bugs] at a time, and they're across tons of projects you didn't even know you were using before you ran this tool, and you don't even know how to contact the people, you kind of get stuck," he said. The only guarantee in the entire disclosure process is that attackers are moving quickly and the time to exploit – that's the time between a CVE's public disclosure and first confirmed in-the-wild exploitation – has essentially collapsed. A clearinghouse for bug reports This may mean that your application is vulnerable to attack even before someone develops a patch. "Then you're putting yourself at risk – and you were already at risk before you ran these scans, but no one else knew about it," Lorenc said. "In an unintended way, [AI] has created this pickle for everyone." In May, Anthropic said it used Mythos Preview to scan more than 1,000 open-source projects, which also underpin much of its own infrastructure, and found an estimated 6,202 high or critical-severity vulnerabilities in these projects. "It's a super awkward, strange world and timeline we are all living in," Lorenc said. "There's a ton of pressure because all of the frontier models are getting better, and the open models are getting better, and they're going to be able to start discovering these at the same time, too. So, that's what we're trying to help with: to be that clearinghouse for critical industry." Athena coalition members submit vulnerabilities they find in open source code using any frontier model. Sometimes they find these bugs while scanning their own apps. In other cases they discover them after pointing Mythos or GPT‑5.5‑Cyber at a commonly used library, Lorenc said. The companies submit a full report to Chainguard, which acts as a clearinghouse, deduplicating, correlating, and addressing findings from members in batches across entire libraries, hardening them against classes of vulnerabilities instead of just one bug. Affected projects are rebuilt as private, hardened versions available to Athena members through Chainguard Libraries before vulnerabilities are publicly disclosed – and hopefully addressed upstream – a month later. For maintainers that can't make a permanent fix, Athena acts as a "maintainer of last resort," according to Lorenc. On Thursday, the Linux Foundation joined the effort and announced Akrites, an industry coalition to defend open source software against AI-enabled threats, by finding and fixing vulnerabilities. Akrites establishes a shared Security Incident Response Team (SIRT) and a standardized Coordinated Vulnerability Disclosure (CVD) process. Founding companies include Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft and GitHub, Nvidia, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone, and Zscaler. "As AI finds more vulnerabilities, the industry will rush to patch them. Without coordination, those fixes will fragment across different patches and forks, and maintainers who are already overwhelmed, unreachable, or haven't touched a project in years," Lorenc said, adding that Akrites provides a coordinated way to fix flaws upstream before criminals exploit them. Plus having a dedicated SIRT gives maintainers a single partner - and disclosure -to work with on remediation instead of a hundred uncoordinated reports. "Now the work is making sure there's always someone on the other end to catch them," Lorenc said. ®

It seems like nobody wants to carry a work phone and that includes even those charged with protecting the US president. The US Secret Service’s extremely lax mobile phone security practices - including using unsecured personal devices during mission operations - put America’s leaders’ and agents’ lives at risk, according to a government-issued report. Secret Service agents routinely used personal cell phones to communicate with law enforcement and each other, including during protective operations in the US and overseas, because their government-issued devices lacked the capabilities they needed to perform their missions, according to a federal review ordered after the 2024 assassination attempt against President Trump in Butler, Pennsylvania. Even when Secret Service employees did use government-furnished equipment (GFE), these mobile devices didn’t have sufficient security to “ensure real-time, continuous protection from cyberattacks by foreign adversaries or individuals,” according to a report by the Department of Homeland Security inspector general. The inspector general’s investigation also found vulnerable apps on these GFE mobile devices. In addition to being prohibited - Homeland Security policy only allows Secret Service employees to use GFE devices for official business - using personal cell phones is especially bad from a cybersecurity perspective. As we have seen time and time again, government employees’ personal devices and private communications provide highly attractive targets for foreign spies or even homegrown criminals plotting attacks against elected leaders. Secret Service agents’ phones can also reveal mission-related details, geolocation - and, by proxy, the US president, vice president, and visiting heads of state’s geolocations - as well as photos, contacts, and other personal information such as family members and home addresses. Since these personal devices are not managed or secured by the US government, it's much easier for attackers to plant surveillanceware and other malware on them. “If a personal device is jailbroken, infected with malicious code, or not up to date on security software, an adversary could intercept device communication,” according to the report. “Outdated and vulnerable apps could enable malicious actors to conduct surveillance, track locations, or record employees’ communications. Connecting to unsecured networks may also allow cybercriminals to access data or install malware.” The inspector general reviewed call and text logs from Secret Service GFE mobile device records from October 2022 through May 2025, and found more than 15,000 instances among 4.8 million calls in which employees sent and received calls from colleagues’ personal phones while working protective events. Investigators also examined travel vouchers for Secret Service employees who travelled internationally between October 2022 and April 2025. They found 30 employees who claimed reimbursement for using personal phones for official, government business. Most of these (23 of the 24 interviewed) said they needed to use their personal cell phones during nearly every foreign assignment. Plus, they used personal mobile devices as hotspots to provide internet access for government-issued laptops, or to access websites blocked on GFE phones. Even when employees did use government-issued devices on overseas trips, these phones also lacked basic security, the investigation found. For example: the Secret Service did not begin installing mobile threat defense software on any GFE phones until August 2025. Nor did the agency consistently wipe data from GFE devices after employees returned from international missions despite Secret Service policy requiring employees to do this within 24 hours of returning to the US. Do these 5 things As a result of its findings, the inspector general made five recommendations to improve mobile device security. These include implementing a formal policy to ensure government-issued devices have all the needed capabilities to ensure mission functions can be conducted securely, and also ensure all employees complete cybersecurity awareness training, as required by the Secret Service. The report also recommends the Secret Service office of the chief information officer do a better job communicating to employees that the use of personal devices is not allowed for official business, and implement controls to wipe all mobile devices returning from international missions. Finally, the inspector general also recommends an updated vulnerability testing policy be applied to all mobile app code. The Secret Service “concurred” with all five recommendations. We reached out to the Secret Service about the report and recommended actions, and a spokesperson declined to comment beyond a letter from Secret Service Director Sean Curran included in the report. Curran said, among other things, that in response to the inspector general’s findings, the agency made “several comprehensive enhancements to Secret Service communications policies and protocols to both mitigate the potential for adversaries to intercept and exploit Secret Service information, as well as further strengthen the protective environment.”®

A high-severity flaw in Amazon's AI coding assistant for Visual Studio Code meant that opening the wrong Git repository could allow an attacker to execute code on a developer's machine and potentially hand them the keys to the dev's cloud environment. The bug, tracked as CVE-2026-12957 and assigned a CVSS 4.0 score of 8.5, centers on how Amazon Q handled Model Context Protocol (MCP) server configurations. Wiz found the extension would automatically load a repository's .amazonq/mcp.json file and execute the commands it contained when a developer opened the project and activated Amazon Q. "The security model assumes the user explicitly configures these servers. After all, you're granting an AI assistant permission to run arbitrary commands on your machine. This should require informed consent," the researchers write. "The vulnerability arose when this assumption was violated: Amazon Q automatically loaded MCP configurations from .amazonq/mcp.json within the workspace – no prompt, no consent, no workspace trust check." MCP lets AI assistants launch local processes to carry out tasks. In Amazon Q's case, those processes inherited the developer's environment, giving them access to AWS credentials, API keys, authentication tokens, SSH agent sockets, and other secrets already loaded into the session. "The combination meant that a single malicious config file could execute arbitrary commands with full access to the developer's credentials – no user interaction required beyond opening the folder and activating Amazon Q," Wiz said. To prove the attack worked, Wiz built a repository with a malicious MCP configuration. Opening the project and activating Amazon Q caused the extension to execute a command against AWS using the developer's existing credentials. Amazon fixed the bug in version 1.65.0 of its language server, which powers Amazon Q's IDE integrations. Existing installations should receive the patched component automatically unless you've blocked automatic updates. "We would like to thank Wiz for collaborating with us on this issue. We have remediated this issue in language server version 1.65.0," Amazon said in an advisory, though it didn't respond to The Register's questions. Wiz argues the bug is less an Amazon problem than an industry one. More and more AI coding assistants are adopting MCP to connect models to local tools and services, allowing them to execute commands on developers' machines. According to the researchers, similar workspace configuration flaws have recently surfaced in other AI coding tools. It suggests attackers have found a new place to lurk: the hidden files that developers rarely think twice about trusting. ®

About the vulnerability

The CVE-2024-2658 vulnerability was discovered in 2024 within the FlexNet Publisher component of the Schneider Electric Floating License Manager. This software handles license management across various Schneider Electric products used for comprehensive industrial automation ranging from PLC programming to centralized control room implementation. Below, we break down how a single flaw can jeopardize an entire industrial facility, how to detect it on your workstations, and how to minimize the risks.

This vulnerability is a CWE-427: Uncontrolled Search Path Element issue. It stems from a system application referencing an OpenSSL configuration file at a hardcoded path without proper access controls.

This behavior allows a local non-administrator to craft a custom OpenSSL configuration file and force the lmadmin.exe system process – the core service that handles licensing – to load a third-party DLL. Consequently, the attacker’s code executes within the context of the service rather than a standard user account. Under specific conditions, this paves the way for further privilege escalation to the NT AUTHORITY\SYSTEM level.

Once NT AUTHORITY\SYSTEM access is achieved, the adversary can gain full control over local configuration files, sensitive system data, and secrets stored on the host. The potential for lateral movement to other nodes in the industrial network – such as engineering workstations – hinges on network connectivity, availability of stored credentials, and overall network architecture. Furthermore, the attacker can disrupt the operation of the license server itself, directly impacting the availability of engineering software and maintenance.

We will examine the role the FlexNet Publisher component plays within the Schneider Electric Floating License Manager (Schneider Electric FLM), why the hardcoded openssl.cnf path inside the application creates a critical hazard, what the exploit chain looks like, and the necessary mitigation steps to secure your environment.

The role of FlexNet Publisher in Schneider Electric FLM

FlexNet Publisher is a third-party commercial product by Flexera Software. The engineers behind Schneider Electric FLM, along with developers of numerous other industry solutions, integrate FlexNet Publisher as a library to manage product licensing. The underlying issue within FlexNet Publisher is that up to and including version 11.19.6.0, the library failed to restrict low-privileged users from modifying or replacing the openssl.cnf file. This is a textbook example of an Uncontrolled Search Path Element vulnerability (CWE-427).

Schneider Electric FLM relies on a combination of tightly integrated components:

1. lmadmin.exe: a lightweight 32-bit daemon that services license requests coming from PLCs, HMIs, and SCADA modules. During installation, this component is automatically registered as a Windows service named lmadminSchneider. The service is configured to launch automatically and executes under the NT AUTHORITY\LOCAL SERVICE account.

   Properties of lmadminSchneider: the executable file and security context of the service

   Properties of lmadminSchneider: the executable file and security context of the service

2. The openssl.cnf configuration file located in the OpenSSL-contrib subdirectory. This configuration file can specify a path to engine-module, a custom DLL file that FlexNet can automatically load into the lmadmin.exe process space. The application references this configuration file via a hardcoded path built into the binary:
   C:\cygwin\home\nightly\LMADMI~1.4\tier1\lmadmin\contrib\openssl\_RELEA~1\openssl\openssl.cnf

   LMADMI~1.4 is the directory name in MS-DOS 8.3 filename format. Any user authorized to create directories in the root of C:\ can recreate this structure – by default, all authenticated users are allowed to do that. A clean, default installation of Schneider Electric FLM does not actually create that folder.

3. The FlexNet Publisher component (historically known as FLEXlm): the license management library that reads openssl.cnf, specifically parsing the [engine] section. If a dynamic_path parameter is defined within that section, FlexNet Publisher will load the specified DLL module at the specified path without performing any checks.
4. The Schneider Electric FLM web portal is a lightweight HTTP server embedded directly within the lmadmin.exe process. It provides access to two main areas: Dashboard (accessible without authentication) and Administration (password-protected). Because the web portal and lmadmin.exe share the same address space, any code loaded via FlexNet Publisher executes directly inside the lmadmin.exe process. This allows an attacker to easily intercept credentials for the Administration portal and leverage them to expand their attack surface across other systems.

SeImpersonatePrivilege assigned to the lmadmin.exe process

The exploit path

To exploit this vulnerability, the attacker must first have the ability to execute arbitrary code locally on the machine hosting the vulnerable service. The primary weakness exploited here stems from standard Windows NTFS permissions: by default, the root directory of the system drive often allows the Authenticated Users group to create new folders. If these permissions (ACLs) have not been tightened, a non-privileged attacker can manually reconstruct the exact directory structure that lmadmin.exe checks for its OpenSSL configuration:

C:\cygwin\home\nightly\LMADMI~1.4\tier1\lmadmin\contrib\openssl\_RELEA~1\openssl\

Next, within this newly created openssl.cnf file, the attacker adds a parameter pointing to a malicious engine module hosted in a writeable directory, for example: dynamic_path = C:\\Users\\public\\malicious.dll. When FlexNet Publisher initializes OpenSSL, it parses this section. Upon finding the dynamic_path parameter, it uses it to load the attacker’s DLL. Because vulnerable versions of FlexNet are allowed to read an OpenSSL configuration from an initially non-existent, untrusted path, the lmadmin.exe process accepts the rogue configuration file as legitimate.

Example of a malicious openssl.cnf configuration file

For lmadmin.exe to parse the openssl.cnf file and execute the malicious DLL, the lmadminSchneider service must be restarted. This can happen under any of the following conditions:

• After a regular reboot of the host machine.
• If the user possesses permissions to restart the service – by default, the Authenticated Users group is not allowed to do that.

Upon lmadmin.exe service startup, FlexNet Publisher initializes OpenSSL, opens the openssl.cnf configuration file, and parses the [engine] section. If a dynamic_path is specified, OpenSSL loads the corresponding DLL module directly into the lmadmin.exe process space. Once loaded, the code within the DLL executes in the context of lmadmin.exe. Because the service runs under NT AUTHORITY\LOCAL SERVICE, the malicious code inherits its privileges.

While the NT AUTHORITY\LOCAL SERVICE account is highly restricted by design, a significant risk for further privilege escalation remains. This exposure exists because, in a standard configuration, the service process is granted SeImpersonatePrivilege. This privilege allows the process to impersonate a client’s security context after authentication. Given an appropriate interaction scenario via RPC, COM, or named pipes, an attacker can exploit this to achieve local privilege escalation to NT AUTHORITY\SYSTEM. This is commonly done with tools from the Potato exploit family or similar impersonation abuse techniques. Consequently, while each individual step may appear unremarkable, their combination forms a complete exploit chain: moving from a low-privileged local user to executing code within a service context, and under the right conditions, to achieving a full escalation to NT AUTHORITY\SYSTEM privileges.

Mitigating CVE-2024-2658

• If your organization does not rely on floating licenses, we recommend completely removing Schneider Electric FLM or avoiding its installation on workstations where it isn’t strictly required. Whenever feasible, use licenses tied to specific machines instead.
• If still required, Schneider Electric FLM should be hosted on a dedicated server with strictly controlled user access.
• Use an administrative account when creating the C:\cygwin directory and explicitly deny write permissions to the Authenticated Users group for this folder. This prevents staging a rogue OpenSSL configuration file along the hardcoded path.
• Finally, update Schneider Electric FLM to version 3.0.0.0 or later.

Detection with Kaspersky solutions

Kaspersky Industrial CyberSecurity successfully detects exploitation attempts targeting this vulnerability. The KICS Vulnerability Manager module flags the presence of the vulnerable software version on endpoints, while the behavioral analysis engine tracks each stage of the attack chain – from the creation of the rogue configuration file on disk to the vulnerable service’s attempt to load the malicious library.

Detecting an exploitation attempt: an overview

The KICS alert card consolidates details on the exploitation attempt alongside recommended defensive actions.

Description The Exploit Prevention component of the EPP application detected attempts to exploit a vulnerability in a protected process. This type of attack may lead to malicious code execution, unauthorized access, or system integrity compromise. EPP application data ● Object name: C:\Program Files (x86)\Schneider Electric\Floating License Manager\FLEXnet Publisher License Server Manager\lmadmin.exe. ● Status: Untreatable. ● MD5 hash: c3f57667d9e8e1b2375ba09cdf71cac8. ● SHA256 hash: 9dab845704d1999ec8ed089594cfd2173a08057f1caf9a2346c22c81039dbb7a. Mitigations ● Analyze the event and identify the source of the startup or interaction with the process. ● Make sure that this vulnerability is relevant to your system (check the software version and installed updates). ● If a vulnerability exploit is confirmed, isolate the device and search for signs of compromise (suspicious files and their checksums, unknown processes/services, or queries to external IPs/FQDNs). Also, check for similar traces on other devices. ● Install security updates for the attacked software or operating system and run a full scan of the device if necessary.

Detecting an exploitation attempt: target process details

Additionally, to proactively identify the presence of the vulnerability on a host as part of a continuous vulnerability management process, organizations can utilize the OVAL scanning task within KICS products. The following screenshot illustrates how KICS for Nodes highlights the presence of the vulnerable software version.

CVE-2024-2658 vulnerability details

Conclusion

The CVE-2024-2658 vulnerability is a prime example of the consequences that dependency-loading mechanisms lacking proper validation can have. In the case of the Schneider Electric Floating License Manager, a local non-administrator can position a rogue openssl.cnf configuration file at the hardcoded path to inject a malicious DLL directly into the lmadmin.exe service context. Given a certain system configuration, this chain can be leveraged to escalate privileges to the NT AUTHORITY\SYSTEM level.

To remediate this vulnerability, organizations must immediately upgrade the affected component (FlexNet Publisher) to a patched version and restrict write permissions for non-privileged users to the C:\cygwin directory. Implementing these controls will significantly reduce exploitation risk, while Kaspersky Industrial CyberSecurity solutions can provide an added layer of defense by detecting anomalous behavior at the earliest stages of the attack.

The Miasma malware campaign has claimed another victim, poisoning more than 20 versions of legitimate npm packages used by the Leo Platform and RStreams ecosystems as its operators continue refining their self-propagating supply chain worm. Microsoft Threat Intelligence said in a post on X that the attack began late on June 24 after attackers compromised an npm maintainer account, "czirker," and used it to publish poisoned updates to more than 20 packages in a "coordinated, fully automated operation completed in under three seconds." Like earlier Miasma campaigns, the malware targets developer workstations and CI runners, hunting for AWS, Azure, and Google Cloud credentials alongside GitHub personal access tokens, Kubernetes secrets, HashiCorp Vault credentials, 1Password data, npm publishing credentials, and other sensitive information. It also scrapes GitHub Actions runner memory before committing the stolen data to a GitHub repository created through the victim's account instead of talking to a traditional command-and-control server. Stealing credentials is only part of the job. The malware also tries to republish any packages the victim is allowed to maintain, sidestepping npm's two-factor authentication and giving itself another route to spread. The malware has evolved too. Earlier Miasma variants relied on npm installation hooks, but according to Sonatype, this version takes a different route, hiding its payload elsewhere in the installation process. It also downloads and executes the Bun JavaScript runtime rather than running everything under Node.js, apparently in the hope of attracting less attention from security software. Miasma is proving difficult to stamp out. The campaign first surfaced in poisoned Red Hat npm packages earlier this month before the Mini Shai-Hulud toolkit landed on GitHub, making the malware available to anyone. Microsoft is urging organizations that installed the affected package versions to assume that developer machines and CI environments may have been exposed. Sonatype recommends checking dependency lockfiles, internal package mirrors, build caches, container images, and CI runners for lingering copies of the malicious releases before rotating credentials. Swap the secrets first, and there's every chance the attackers simply steal the replacements. ®

ON CALL Supporting IT and keeping it secure is a serious endeavor. Which is why The Register lightens up Friday mornings with a fresh installment of On Call, the reader-contributed column that shares your tales of tech support trauma. This week, meet a reader we'll Regomize as "Colin" who told us about a recent gig at a customer that decided to improve the security of its Microsoft 365 implementation – chasing the Secure Score that Redmond uses to rate resilience. "We spent a good amount of time working with the customer and agreed a rollout plan to ensure multi-factor authentication (MFA) was enabled across the board in accordance with a security baseline." Colin and his crew knew what to do, so when they flicked the switch on various upgrades, all went smoothly. Until it didn't. "The following morning, one of the senior directors of the company – who was allegedly the COO of a cybersecurity company – called our service desk and started yelling." Amid the yelling and accusations, Colin and his colleagues picked out an allegation that the company had been brought to its knees by the need to register for MFA, which had crippled an invoicing system and would surely result in ruin within a disastrously short time frame. "Once she allowed us to speak, it turned out that the problem only impacted three or four phones," Colin wrote. The support team investigated and quickly learned the real problem was with the invoicing software, which promised MFA support but relied on buggy software to make it happen. The director didn't care for that explanation and ordered an instant rollback that we understand remains in place. Colin found it stunning that the former COO of a security company wasn't willing to wait for a workaround, so delivered the desired result: no MFA, and worse security. He told us this client often made nonsensical requests, such as demanding that a particular engineer – who cannot drive – visit a remote site ASAP to fix a printer. On another occasion, the same person claimed Colin's work on M365 caused a power outage! Have you ever been told to make IT worse? If so, click here to send On Call an email so we can make the column better on a future Friday. ®

Chinese cybersecurity vendor Qihoo 360 claims it’s built an AI bug-finder that’s better than Anthropic’s Mythos model. CEO Zhou Hongyi revealed the model in a speech at the 14th Beijing Cybersecurity Conference, which Qihoo 360 organizes. Chinese media outlets have transcribed the talk, in which Zhou described Mythos as “equivalent to a ‘cyber nuclear weapon’,” because the USA’s ban on foreign nationals accessing the model gives America a tool with which to find flaws in software upon which other nations rely. Zhou thinks China needs equivalent capabilities as a deterrent, but suggested replicating Mythos is not a viable approach. “Mythos follows a typical large-scale model approach: the strongest model, the strongest computing power, and the strongest chips – a strategy of sheer brute force,” he said. “However, this path has an implicit prerequisite: your model capabilities must be sufficiently strong. Objectively speaking, domestically developed models still lag behind by 20 percent to 30 percent in underlying capabilities.” The CEO therefore thinks China can’t wait for its own models to catch up and needs to find another way to build Mythos-grade bug-finders. Helpfully, Qihoo 360 has found those alternative methods by distilling its 20 years of experience fighting cyber-threats and colossal malware library into security-specific models and agents. The company has put that to work in what Zhou described as a “multi-agent swarm.” “If the American approach is about cultivating a genius hacker, the 360 approach is about organizing a professional attack and defense team,” he said. “When faced with a target, the swarm doesn't perform single-point analysis, but rather collaborates: first, it models the threat and filters high-risk attack surfaces; then, it follows the data flow across files to discover potential vulnerabilities.” The company’s agents apparently “automatically build sandbox environments, automatically generate exploit code, and conduct real-world testing. The result is that every vulnerability is ‘confirmed’ rather than just suspected. After completing a task, the swarm also summarizes and reviews its performance, becoming smarter with each use. This is something a single large model can hardly do.” Qihoo calls this approach “Tulongfeng” and says it’s already finding flaws in open-source and commercial software. “We automatically discovered a Windows kernel privilege escalation vulnerability that had been dormant for five years, an Office remote code execution vulnerability that had been dormant for eight years, and an Excel vulnerability that had been dormant for 10 years, earning official recognition from Microsoft,” Zhou boasted. The CEO said the tool found plenty of flaws in OpenClaw – a feat that human researchers have also achieved. Zhou said Qihoo 360 has created another AI-powered security tool called “Yitianzhen” that automatically simulates potential attacks against an organization’s cyber-defenses, then suggests and/or implements remediations. The company has created an alliance of local cybersecurity companies to use it and create a bulwark against Project Glasswing – the group of entities Anthropic allows to use Mythos under controlled conditions. US authorities have sanctioned Qihoo 360 on grounds that it probably supplies China’s military. China's National Computer Virus Emergency Response Center (CVERC) often cites and publicizes the company’s research, sometimes in its documents that allege the US hacks itself to make China look bad. ®

A new self-destructing backdoor called Mistic used in intrusions since April appears to be linked to a criminal gang that compromises corporate networks and then sells that access to ransomware groups, according to security researchers. This backdoor, also tracked as MLTBackdoor, was first documented by Zscaler earlier this month, with the security shop suggesting the novel malware is “likely used in ransomware attacks to establish a foothold for lateral movement.” In a Wednesday threat brief, Symantec and Carbon Black threat hunters say the backdoor has been used to access multiple organizations' networks over the past few months, including those in insurance, education, IT, and professional services. Additionally, the security sleuths reported, “Mistic may be linked to the financially motivated initial access broker (IAB) tracked publicly as KongTuke (which we track as Woodgnat) and it was used in one intrusion that also involved the group's ModeloRAT remote access trojan.” KongTuke and other IABs don’t deliver the final payload – such as ransomware – to compromised companies. Rather, they break into company systems, and then sell that foothold to other criminals, like ransomware gangs. Symantec and Carbon Black arrived at their low-confidence attribution after at least one case where Mistic was deployed in close proximity to ModeloRAT, the Python-based remote access trojan KongTuke also developed. KongTuke has previously been linked to attacks from various ransomware crews including Qilin, Interlock, Rhysida, Akira, 8Base, and Black Basta. “Our Threat Hunter Team has separately observed ModeloRAT used in attacks that deployed Qilin ransomware, linking this tool to ransomware deployment,” Symantec and Carbon Black noted. Plus, Zscaler reported Mistic being delivered in a multi-stage ClickFix infection chain, which is another pointer to KongTuke, as the group is known to use that initial access technique. In one case that Symantec and Carbon Black responded to, Mistic was side-loaded through a legitimate file, MpExtMs.exe, and then loaded from a DLL named EndpointDlp.dll, which likely helped the backdoor blend in with legitimate software. Mistic has all the usual backdoor functionality: It can upload, download, move, rename, and delete files. It can also create new folders, and check for additional commands from the attacker-controlled command-and-control (C2) server. But here’s the stealthy part: it can run remote payloads from C2 directly in memory – so it doesn’t write malicious files to the hard drive – which helps it dodge file-based detection in antivirus and endpoint detection products. When the mission is accomplished, it then terminates and deletes itself. “The fact that Mistic executes in memory and also has a kill switch built in means that it is very stealthy, potentially allowing for long-term, stealthy access for attackers,” the threat hunters wrote. ®

Security firm Huntress allegedly has a turncoat insider leaking info to a ransomware operation, according to an ex-employee who took his grievances to social media after claiming the security shop tried to “silence” him with legal threats. And it all started with a Pinocchio GIF and clown emoji. Late last week, Huntress disclosed that it is among the “hundreds of Klue customers” compromised in the supply-chain attack, stating that “Huntress believes in radical transparency about security incidents, including when it affects our company.” Ben Folland, a former security operations analyst at Huntress who left the company in February, responded with a Pinocchio GIF and clown emoji - although, to be clear, his complaints about his former employer have nothing to do with the Klue incident. These stem from an earlier incident that Folland also detailed in a series of posts. According to Folland’s resignation letter, which he also shared on LinkedIn, he left the security firm for “personal reasons, and due to a conflict of interest,” with his last day of work being February 19. This conflict, Folland alleges, arose from his December discovery that “another Huntress employee passed communications from US law enforcement to a cybercriminal, DevMan, who is actively and publicly targeting my family and me.” DevMan is a ransomware operation that first emerged in April 2025 and uses modified DragonForce code. “Since December 2025, I believe Huntress has been actively trying to conceal a serious security incident from its partners, customers, and employees involving an insider who is still employed at the company,” Folland said in a LinkedIn post. The alleged insider was “caught by the FBI,” according to Folland, and continues to work as a Huntress employee. “The incident in question would cause significant reputational damage to Huntress and, in my view, continues to put clients at risk,” his LinkedIn post continued. “With an IPO on the horizon, it appears their priority was not transparency, but keeping this away from the press.” Folland also promised to publish, over the next two weeks, “evidence supporting the claims made in my resignation email,” such as communications with the FBI and those between the Huntress employee and DevMan, recorded phone calls, internal Huntress memos, and threats targeting Folland and his family. The Register reached out to Folland for more information and did not receive a response. “If you are an employee at a cybersecurity company, you should not be helping cybercriminals,” he wrote on LinkedIn. “You should not be informing them of active investigations. You should not be engaging in cybercriminal activity yourself.” We also contacted Huntress about Folland’s accusations, and CEO Kyle Hanslovan responded via a spokesperson. "A former employee raised concerns that a teammate exercised poor judgment in communicating with a cybercriminal,” Hanslovan said. “By nature of our work as security researchers, teammates occasionally need to communicate with possible cybercriminals to gather intel that ultimately supports our partners and customers,” he continued. “I appreciate the hell out of that former employee's concerns and we've taken them seriously every step of the way. I also have to make sure Huntress upholds its responsibility to protect the confidentiality of our teammates involved and the investigation underway.” Hanslovan also assured Huntress’ partners, customers, and employees that if he learns “new information that changes our assessment of the current situation, I will take quick and appropriate action.” In a more direct response on Reddit, Hanslovan said he “firmly disagree[s]” and doesn’t “understand Ben's accusations.” His company “strongly disagree[s] with this ‘insider’ narrative,” he wrote. “We sure af didn’t prioritize an IPO over the safety of our partners, customers, or team.” And about the FBI allegations: “Some aspects of this matter involve ongoing active coordination with law enforcement and legal proceedings that prevent us from providing a complete public account,” Hanslovan wrote. “We're not gonna litigate this on LinkedIn with Ben but will likely publish some form of official comms to make our stance clear for those needing something more than my reddit reply.”®

Small and medium-sized businesses (SMBs) remain attractive targets for cybercriminals – in both mass cyberattacks and sophisticated campaigns targeting larger enterprises through trusted relationship attacks. At the same time, smaller businesses may lack the robust cybersecurity policies and necessary resources to protect themselves against an evolving threat landscape.

Kaspersky believes that raising awareness can help small and medium-sized enterprises develop an effective protection strategy. Ahead of International SMB Day on June 27, Kaspersky presents the findings of its 2026 threat analysis for SMBs, which includes real-world examples of attacks.

Key findings

• In the first four months of 2026, Kaspersky solutions detected over 33,300 cyberattacks on SMBs masquerading as popular artificial intelligence (AI) tools – almost five times more than in 2025 and 39% more than the number of attacks disguised as the office and collaboration tools that Kaspersky’s research focuses on.
• Popular messengers and communication services remained the attacker’s most widespread lure, with almost 415,000 attacks involving fake messenger apps and video conferencing software.
• The attackers follow trends: the AI tools Claude and OpenClaw (ex-ClawdBot/MoltBot), which have gained popularity in 2026, were among the common AI lures.
• Fraudsters use fake AI tools to scam businesses out of money, while corporate accounts on social media also remain targets.
• The majority of initial accesses to corporate infrastructures sold on the dark web are allegedly accesses to SMBs. This could be because SMBs tend not to be as well protected as large enterprises and, at the same time, may be trusted contractors for those well-protected enterprises.

Malware and potentially unwanted applications (PUAs) disguised as popular services

Kaspersky researchers used data from Kaspersky Security Network (KSN) to explore how frequently malicious and unwanted files are disguised as legitimate applications that may be used by SMBs. KSN is a system for processing anonymized cyberthreat-related data shared voluntarily by Kaspersky users. For this part of the report, only anonymized data received from users of Kaspersky solutions for SMBs were analyzed.

According to a survey by the Small Business & Entrepreneurship Council (SBE Council), small business owners continue to embrace artificial intelligence and digital transformation as they maintain a generally positive outlook on the economy. Threat actors are also aware of the hype surrounding AI and exploit it for their own benefit. In particular, they actively distribute cyberthreats under the guise of popular AI services.

From January to April 2026, Kaspersky solutions detected 33,352 attacks on SMB users in which malware or potentially unwanted applications for PCs were disguised as five popular AI services. This figure represents an increase of almost five times compared to the previous year. This highlights an evolving trend in which threat actors are weaponizing trust in widely used AI platforms and services, especially popular ones like Claude. Kaspersky experts note that it’s important to download apps from official sources and to verify which apps are available for which platforms.

Share of attacks targeting SMBs in which malware or PUAs mimic the five popular, legitimate AI apps that Kaspersky’s research focuses on, first four months of 2025 and 2026 (download)

In the first four months of 2026, Kaspersky researchers also identified more than 1,100 unique samples of malware and PUAs detected in the SMB sector that masqueraded as five popular AI applications, representing a 21% increase compared to the same period of 2025. The samples were mainly different types of Trojware (Trojans and Trojan-like malware), including those capable of downloading and running other malware on compromised devices. Trojware disguises itself as harmless files to trick users into installing them. Their functionality may vary depending on the particular type of Trojware. This may include stealing, deleting, blocking, modifying or copying users’ data, as well as other malicious actions. Trojware therefore represents a highly dangerous cyberthreat to entrepreneurs and businesses.

Kaspersky experts also note that the threat landscape is constantly evolving with new lures appearing all the time. For example, in the first four months of 2026, Kaspersky solutions blocked hundreds of attacks in which malware or PUAs for PCs were disguised as OpenClaw (previously known as Clawdbot or Moltbot).

Other lures for SMBs: Fake communication apps and office software

Kaspersky analysts also explored how attackers leverage other legitimate applications as lures to target SMBs. For example, from January to April 2026, Kaspersky solutions blocked 414,736 attacks on SMB users in which malicious software or PUAs for PCs were disguised as the popular communication apps that Kaspersky’s report focuses on. The number of attacks changed marginally compared to the previous year’s figure, indicating that the lure of fake communication apps remains a serious cyberthreat.

Share of attacks targeting SMBs in which malware or PUAs mimic the four legitimate communication apps covered by Kaspersky’s research, first four months of 2025 and 2026 (download)

Various fake office applications and collaborative platforms also remain among the lures that attackers may exploit to target SMBs. According to Kaspersky telemetry, more than 24,000 attacks were detected from January to April 2026 in which malware or PUAs for PCs were disguised as specific office applications.

Share of attacks targeting SMBs in which malware or PUAs mimic the six popular office applications and collaboration tools covered by Kaspersky’s research, first four months of 2025 and 2026 (download)

In 2026, AI-related baits have become more widespread among cybercriminals than traditional fake office and collaboration tools. Kaspersky experts note that the more publicity and hype there is around certain tools, the more likely a user is to come across a fake package online.

Scammers and phishers tricking victims into providing credentials and funds

In 2026, Kaspersky researchers observed a wide range of phishing campaigns and scams targeting businesses and entrepreneurs. Fraudsters mimic financial and AI services as well as other platforms in order to steal credentials, personal information and funds.

In the following example, fraudsters disguise themselves as a bank that allegedly offers services for businesses (in other similar schemes they may offer business loans). Entrepreneurs are prompted to visit a scam website and enter their data to open a business account. The requested information varies depending on the scam, but may include name, email address, phone number, social security number, date of birth and address. Scammers may then use this data in their schemes or sell it on the dark web.

Kaspersky experts advise: if you encounter such a website, you should not rush to enter any data. First, examine it. Does the purported financial organization actually exist? How old is the website? Check the WHOIS records and read user reviews before entering any information on the page.

Example of a scam page targeting entrepreneurs

As with many other cyberthreats, AI services are also leveraged as a lure in scams. For example, Kaspersky experts identified a scam website for an AI service “built for contractors”. According to the text on the fraudulent page, the tool can help with “estimates, invoices and schedule”. However, in reality, in such schemes victims usually receive nothing after paying for a subscription, while the scammers get all the money.

Example of a scam page promoting an AI tool

Kaspersky experts note that business accounts on social networks and messengers remain attractive targets for cybercriminals in 2026. In one scheme, phishers distributed notifications with fake alerts related to companies’ business pages. The notifications claimed that Facebook’s review system had detected behavior that seriously violated its Community Standards and Advertising Policies. To avoid permanent restriction of their business page on the social network, owners were prompted to fill out an appeal form and provide personal and business email addresses, phone numbers, as well as the name of their business page and the password for their social network account. The attackers’ goal was to obtain credentials. To reduce user vigilance  and appear legitimate, fraudsters also sent victims a fake appeal code.

Example of a fake notification

Email threats: Fake online documents and exploitation of legitimate platforms

Email remains one of the most widely used channels for cyberattacks targeting enterprises, including small and medium-sized businesses. In 2026, attackers have frequently combined email distribution with the exploitation of legitimate third-party platforms. This is how phishers and scammers usually attempt to bypass traditional email filters and exploit user trust in reputable services. Kaspersky researchers have also observed a large number of schemes targeting corporate users in which phishers and scammers use fake online documents or nonexistent meetings as bait.

In one recent scheme detected by Kaspersky, the attackers sent a fake notification disguised as a letter from OneDrive. The victim was prompted to access the document by clicking a button, but in reality, it led to a phishing website where users risked losing their confidential data. To make the email appear legitimate, the attackers added a phrase designed to  lower the victim’s vigilance: “This item is encrypted and hosted within your secure cloud perimeter.” They also parsed the recipient’s email address and used the extracted data in the fake notification text so that the email looked like a standard notification from this type of service: “[email address domain as company name] has successfully uploaded a new file for [the user’s name as stated in their email address].”

Example of a phishing scheme with fake online documents

Attackers also use other pretexts to trick victims into sharing confidential information, for example fake compliance issues. In the example below, the attackers posed as Apple representatives. The fake notification stated: “Apple has identified a compliance issue related to Google Ads campaigns directing traffic to Apple product detail pages associated with the victim’s seller account.” However, the button in the email led to a phishing website where users are tricked into sharing confidential data.

Example of a fake compliance issue notification

Kaspersky experts observed another notable two-stage scheme aimed at stealing credentials from corporate emails, which involved distributing an invitation to a nonexistent meeting. The scheme is deployed in two stages. In stage one, a corporate user receives an email about a fictitious meeting. After clicking the “Accept Meeting Invitation” button, the user is redirected to a legitimate Zoom Docs (previous Zoom canvas brand) page. In stage two, the victim is prompted to click a hyperlink that reads “Click Here to Accept Meeting”. However, the URL of a phishing page is hidden behind this hyperlink.

Example of an email with a fake meeting

Zoom Docs page containing the phishing link

Malware is also actively distributed via email. In 2025, individuals and corporate users encountered over 144 million malicious and potentially unwanted email attachments, representing a 15% increase from the previous year.

Kaspersky experts note that the lures used in subject lines and texts of malicious emails can appear relatively harmless and rather unsophisticated. In the example below, the attackers target businesses with a fake request for “the best quote for the items attached.” However, the attached file actually contains a Trojan.

Example of a malicious email

Corporate infrastructure access for sale: Posts on the dark web

To assess threat actor activity, Kaspersky Digital Footprint Intelligence experts analyzed hundreds of posts offering initial access to corporate infrastructures published on dark web forums from January to April of both 2025 and 2026. Kaspersky experts note that a single post may contain several offers for access to different allegedly compromised companies.

Example of a post on a darknet forum

Initial access brokers (IABs) sell initial access to compromised businesses, for example, via RDP or web shells. In their posts, IABs may provide information about the region where the allegedly compromised companies are located, their industry and revenue, as well as the type of access. IABs sell access that the buyers can then use for different purposes, including ransomware attacks, stealing corporate confidential information or other fraudulent activity. The price of initial access on dark web forums may depend on the revenue, industry or location of the allegedly compromised companies, or on the access privileges. For example, accounts with admin rights are usually more expensive because they can provide attackers with a wide range of possibilities.

According to the research, there were more posts offering initial access to companies of different sizes located in the Middle East (up 53% from last year), Africa (up 40%) and Latin America (up 17%). Meanwhile the number of posts related to companies located in Europe decreased by 34%. According to Kaspersky experts, this decline can be partially explained by the closure of a dark web forum containing such posts around the time of the study. The number of publications related to companies located in the APAC region also decreased slightly (down 4%), but remained at a consistently significant level for the second year in a row.
At the same time, the number of posts where the region was not specified decreased by 56% in 2026 compared to the previous year. Kaspersky analysts assume that this may indicate that initial access posts from IABs are becoming more targeted and unique.

Share of posts with initial access offers by business size

For this research, Kaspersky experts defined a small business as having an annual revenue of up to US$50 million, and a medium-sized business as having an annual revenue of between US$50 million and US$1 billion.

According to Kaspersky’s research, at the beginning of 2026 the share of posts on dark web forums with offers of initial access to allegedly compromised small businesses was larger than the shares of posts offering access to medium, large or nonprofit organizations. However, this share decreased in the first four months of 2026 compared to the same period in 2025. The share of posts concerning medium‑sized organizations also remained significant for two consecutive years. Taken together, posts concerning small and medium‑sized organizations account for more than half of all the analyzed posts with initial access offers on dark web forums.

At the same time for a certain number of posts initial access brokers didn’t indicate companies’ revenue, therefore, making it impossible to determine the size of the company.

Share of posts with initial access offers by business size, January–April 2025 (download)

Share of posts with initial access offers by business size, January–April 2026 (download)

Kaspersky experts note that despite the prevalence of posts concerning small businesses, threat actors may target medium‑sized businesses because they generate higher revenues than small businesses and may have weaker security defenses than large businesses.

SMBs can also become targets as a part of trusted relationship attacks, which enable the attackers to reach larger organizations. According to the Global Report by Kaspersky Security Services, the share of trusted relationship attacks among the initial vectors increased from 12.7% in 2024 to 15.5% in 2025. Therefore, the common belief that small and medium‑sized enterprises are of no interest to attackers is a misconception. Companies of all sizes need to understand the cyberthreat landscape, adhere to cybersecurity rules, implement appropriate cybersecurity solutions, and continuously improve employee awareness.

Cybersecurity action plan for SMBs

SMBs can reduce risks and ensure business continuity by investing in comprehensive cybersecurity solutions and increasing employee awareness. To protect themselves from the ever-evolving threat landscape, companies are advised to follow these rules:

1. Define access rules for corporate resources such as internet services, email accounts, shared folders, and online documents. Keep access lists up to date and revoke access promptly when employees leave the company.
2. Regularly back up important data to ensure the preservation of corporate information in case of emergencies.
3. Establish clear guidelines for using external services and resources. Create well-defined procedures for coordinating specific tasks, such as implementing new software, with the IT department and other responsible managers. Develop short, easy-to-understand cybersecurity guidelines for employees, with a special focus on account and password management, email protection, and safe web browsing. A well-rounded training program will equip employees with the necessary knowledge and ability to apply it in practice.
4. Raise employees’ security awareness. Conduct dedicated training to teach staff how to detect and address potential threats, and track their educational progress. Organizations can achieve this with the Kaspersky Automated Security Awareness Platform through interactive online modules and simulated phishing campaigns that build sustainable cyber hygiene habits across all teams.
5. Implement specialized cybersecurity solutions that fit your budget, size, and industry requirements, with an emphasis on scalability and ease of integration.
   1. Kaspersky Small Office Security Premium is an easy-to-use solution that protects against advanced threats and also provides access to security awareness training for employees, making it ideal for micro-businesses.
   2. Small and medium-sized enterprises with more mature IT expertise should consider Kaspersky Next Optimum, which is designed specifically for growing organizations and offers real-time protection, threat visibility, as well as EDR and XDR investigation and response capabilities.
6. Protect your business against email-borne threats. Kaspersky Security for Mail Server, a comprehensive email security platform that offers robust, multi-layered protection at mailbox and gateway levels, can help with this. Powered by machine learning and leading global threat intelligence, it effectively addresses all mail security challenges.
7. Adopt specialized solutions such as Kaspersky Digital Footprint Intelligence to monitor the surface, deep, and dark webs for information about a company’s credentials, leaked data, and lookalike websites. Small and medium-sized companies with limited IT security budgets can partner with a managed security service provider (MSSP) to access this comprehensive digital risk protection service at an affordable, subscription-based price point.

PWNED Welcome back to PWNED, the weekly column where we school ourselves on others' security failures. This week, we’ll learn about a school where the entire network was like an open-book test … and the IT department got a zero. Have a story about someone leaving a gaping hole in their network? Share it with us at [email protected]. Anonymity is available upon request. Our tale of academic pwnage comes courtesy of a reader we’ll Regomize as Nathan. Nathan was 17 and attending sixth form at a UK school when he found a treasure trove of admin privileges and data at his fingertips. One day, our hero connected his laptop to his school’s Active Directory domain. There was no admin authentication required and Nathan was able to see domain controller tools in view mode, look at policy maps, and so on. Nathan then browsed the directory and located the domain administrator account. The password, “horse fence ditch,” was written right in the description field, where anyone with access to the network could view it. There were also backup accounts with passwords such as “bd” and “bigbaddog.” Once he had full God mode enabled, Nathan said, he could see student and staff data, gain Remote Desktop access to any server or domain controller, and even access LanSchool, a popular classroom management app. “I could've accessed sensitive leadership docs, reset passwords, deleted accounts, wiped the whole network, etc,” Nathan told The Register. Moreover, the entire system was synced with Google Workspace, so Nathan had access to user mailboxes as well. He even found firewall settings, security policies he could change, and keystroke histories. Because Nathan was a student and did not want to get in trouble at school, he didn’t actually use any of these privileges. He kept his head down and graduated from school without incident, but also without reporting the vulns, which might still be in place today for all we know. So what can we learn from this tale of academic malpractice? First, as we learned a few weeks ago, do not store passwords in description fields for Active Directory. In fact, do not store passwords in cleartext anywhere without serious controls! Second, Nathan should not have been able to see Active Directory domain controller tools. And it might also have helped if Google Workspace had different admin credentials. Imagine the restraint required not to change people's grades, take over their computers, or delete data. Would you have been able to exercise the same level of discipline as a 17-year-old? ®

Australia’s Security and Intelligence Organisation (ASIO) has established dedicated teams to counter nation-state attacks on critical infrastructure, the org’s director general Mike Burgess revealed yesterday. “We discovered nation-state hackers had compromised the network of an Australian critical infrastructure provider,” Burgess said yesterday in remarks accompanying the release of ASIO’s annual threat assessment, a task it performs in its role as Australia’s equivalent to the FBI and MI5. “ASIO assessed the hackers were preparing for sabotage. They weren’t planting ‘digital dynamite’ as such; they were mapping out the network and maintaining access so they could cripple it at a time of their choosing.” “In this case, a state-sponsored group didn’t just achieve access to the Australian critical infrastructure provider, it successfully acquired credentials – login details and passwords – for active users of the networks, including the IT professionals guarding it,” he added. Burgess said ASIO “identified, tracked and attributed the hack, and worked with the victim company and our security partners to remediate the compromise – work which is ongoing.” “The scale of this activity – led by one nation-state in particular – is difficult to overstate,” he added, before saying Australia is not alone in facing such attacks. “We struggle to find a single country in our region that has not been compromised by this state’s cyber apparatus.” He described cyber sabotage as “an evolving threat. I have established dedicated teams to counter it.” Burgess also shared an example of espionage targeting Australia’s military to gain information about the AUKUS pact – the US/UK/Australia defense collaboration that will see The Land Down Under acquire nuclear submarines, and which also includes collaborations around information technology capability, and intelligence activities. “A spy from a foreign intelligence service approached an Australian security clearance holder online, pretending to be from a consulting company,” Burgess revealed. “The spy paid the official to write two reports on Australia’s relationship with our Pacific neighbours, and then, thinking he’d been hooked, offered money for inside information on AUKUS.” The Australian official became suspicious, reported the incident and conducted interviews with ASIO during which Burgess said the spy agency “gained valuable insights into the foreign service’s information gaps and tradecraft.” The Australian official even handed the money they were paid by the foreign spy to ASIO. “In effect, ASIO disrupted the foreign intelligence service’s operation and made them pay for it,” Burgess crowed. ASIO then scored another win. “My officers borrowed the phone from the official and rang the so-called consultant in her home country. Thinking it was her target, the spy picked up and got a very unwelcome surprise when she realised she was speaking to ASIO,” Burgess said. “We demonstrated we knew exactly who she was, demanded she cease targeting Australian citizens, stated we have zero tolerance for spying on AUKUS, provided a quick overview of Australia’s espionage laws and pointed out the Director-General reserves the right to speak publicly about these matters. At that point the spy hung up.” ASIO officers later mentioned this incident to members of the foreign intelligence service that ran the op. Burgess seems to think that officers at that foreign agency may not have told their superiors about the op failing. “In case they did not report it up – I’m confirming it now,” he said. Burgess also pointed to abuse of online spaces continuing to represent a threat to Australia. “Instead of being radicalised by associates in the real world, individuals are often being radicalised by strangers online,” he said. “Instead of being radicalised over months and years, individuals are increasingly being radicalised in weeks. Instead of being radicalised as adults, individuals are all too often being radicalised as minors. Instead of gathering in prayer halls or backyards, radicalised individuals are frequently gathering in encrypted chat rooms.” “And, instead of spending time and resources planning sophisticated attacks, radicalised individuals are moving to low-capability attacks with little or no warning,” he said. “Traditional groups such as Islamic State and al-Qa’ida and their affiliates are growing their capability to conduct and inspire attacks, enabled both by permissive geographic and online spaces.” Burgess revealed ASIO has “resolved” 14 “significant-terror related cases” since the December 2025 terror attack at Sydney’s Bondi beach, and 31 “major terrorism plots” since 2014. He said ASIO is now “aggressively adopting new tools and techniques – including artificial intelligence – to navigate our security environment,” and invited Australians to work for the agency, perhaps as offensive hackers. “All ASIO’s teams contribute to our mission and every ASIO officer makes a difference, whether you collect the dots or connect the dots, run cables or run sources, code networks or penetrate networks,” he said. ®

It’s looking like another tough week (month? year?) for Switchzilla amid reports of new serious vulnerabilities under attack. First up is a server-side request forgery bug in its Unified Communications Manager tracked as CVE-2026-20230. Cisco disclosed and patched this flaw in early June. The comms control platform doesn’t properly validate some HTTP requests, and an attacker could exploit this bug to gain root privileges on a compromised device. At the time, Cisco said that a proof-of-concept exploit was available – and now it seems unknown miscreants are putting that exploit code to use, with threat intel company Defused warning that it observed miscreants exploiting CVE-2026-20230 over the weekend. “The observed chain abuses the WebDialer SSRF to deploy a rogue Apache Axis service, uses that service to write a first-stage JSP file-writer, then drops a second-stage command-execution shell under /platform-services/axis2-web/,” the firm noted on LinkedIn. Cisco Catalyst SD-WAN zero day Then, a Mandiant advisory on Wednesday warned that a Cisco SD-WAN zero-day tracked as CVE-2026-20245 was exploited much earlier than initially disclosed, including at a communications service provider where the attacker elevated a compromised admin account to full root-level access. "Mandiant suspected it might be a zero-day during its initial investigation, but deeper forensic analysis was required to confirm the exploit of a new flaw. The June date in Cisco’s advisory reflects when the vulnerability was officially validated, patched, and publicly disclosed," Pete Boonyakarn, Senior Cyber Security Consultant, Mandiant - Google Cloud, told The Register. While the Google-owned threat hunting biz said it can't assess the full scope of the intruders' post-compromise activity, this SD-WAN device compromise could have been dire, potentially giving the attacker total visibility across an entire corporation's internet traffic. This is what makes SD-WAN zero-days such a hot target for government-sponsored spies looking to set up shop for long-term snooping activities. It also explains the rash of attackers battering Cisco SD-WAN devices since the start of the year. Cisco had issued an advisory for CVE-2026-20245 in early June, admitting that attackers had a head start on abusing this security hole. “In June 2026, the Cisco PSIRT became aware of exploitation of this vulnerability,” the vendor said at the time. In a Wednesday report, however, Google’s Mandiant incident response and consulting biz reported that exploitation of this bug – Cisco’s sixth SD-WAN vulnerability listed as under attack since the start of the year, and the second zero-day in two months – began much earlier. “In early 2026, Mandiant identified a threat actor targeting SD-WAN infrastructure at a service provider,” Mandiant threat hunters Chester Sng, Pete Boonyakarn, and Logeswaran Nadarajan wrote. “After gaining initial access, the threat actor exploited a zero-day vulnerability (CVE-2026-20245) in Cisco Catalyst SD-WAN to escalate privileges from a compromised administrative account to root-level access.” The attacker gained initial access via an unauthorized peering connection, abusing the SD-WAN fabric to authenticate between network components and facilitate Secure Shell (SSH) access. In this case, they authenticated to the SD-WAN manager device via SSH using the vmanage-admin account on the same victim devices. Then, they changed the default password on the admin account, authenticated directly to the SD-WAN Manager web application interface using the admin account, and exfiltrated SD-WAN fabric configurations. Likely in an effort to cover their tracks and not get caught, the attacker changed the password of the admin account back to its original one before terminating their active session. Neither the vmanage-admin nor the admin accounts on Cisco Catalyst SD-WAN controllers possess root shell access, however. To gain root access, the attacker exploited CVE-2026-20245, which allows an authenticated, local attacker to execute arbitrary commands as root by supplying a crafted file to the vulnerable system. The attacker uploaded a file named evil_tenant.csv that contained the exploit payload. Upon execution, the digital intruder created a user account named troot with full root privileges. Mandiant says it later observed the miscreant accessing this new troot account from the admin account using the substitute user command. The Register reached out to Cisco about the reported exploitation of CVE-2026-20230, and Mandiant’s investigation into CVE-2026-20245. The company pointed us to its June advisory on the latter matter, and is working on response to our first question. ® Updated on June 25 to include quote from Mandiant.

Microsoft, its friends, and international law enforcement - with an AI assist - disrupted two widely used pieces of malware and their infrastructure, in what Redmond describes as a novel approach to cybercrime disruption that targets the cyberattack supply chain instead of a single tool or service. “What’s new is how we’re combining AI analysis with an expanded use of that law,” Steven Masada, assistant general counsel for Microsoft’s Digital Crimes Unit, said in a Wednesday blog, referring to the Racketeer Influenced and Corrupt Organizations Act (RICO). Typically Microsoft uses RICO and other US laws to take legal action against a single cybercrime service or infrastructure. The disruption involved the takedown, suspension, and blocking of more than 200 domains and command-and-control (C2) servers that formed the backbone of StealC and Amadey infrastructure. Multiple security companies, including ESET, BitSight, Mitsui Bussan Secure Directions (MBSD), IBM X-Force, and Proofpoint, also played a role in dismantling the alleged operations. Combined with the earlier SocGholish disruption announced last week, a Europol-led law enforcement coalition flagged and restricted cryptocurrency assets valued at more than $47 million and recovered about 27 million stolen credentials. StealC and Amadey are two separate malwares developed by different criminal crews, but they used the same infrastructure and were operating in concert. StealC collects multiple browser credentials and cookies, cryptocurrency wallets, chats from messaging apps, and other sensitive data, and exfiltrates the stolen goods to a C2 server. It also works as a secondary loader, allowing criminals who rent the stealer to download additional malware on compromised devices. Amadey is a malware-as-a-service used to deliver StealC and other stealers, plus other types of malware including remote access trojans, cryptominers, and ransomware. In just the first two weeks of May, Amadey and StealC were linked to more than 140,000 infected computers globally, according to Microsoft. “It’s no longer enough to go after threats one by one,” said Masada. “We need to interrupt how the attacks are put together.” In this case, Redmond’s investigators used Copilot and other AI tools to analyze both malwares and their infrastructure, “asking questions in plain English instead of manually combing through complex code,” Masada wrote. “That helped surface key details, uncover hidden data, and test findings in a fraction of the time, turning what would have taken hours or days into minutes and enabling the team to spot connections faster.” One of these key details: both Amadey and StealC used the same infrastructure. This allowed Redmond’s legal team to treat both malwares as part of a single conspiracy under RICO and bring civil claims against five defendants allegedly involved across both operations. “Defendants comprise a group of cybercriminals operating a Malware as a Service enterprise that leverages malicious software commonly known as the Amadey Malware Suite and StealC Malware Suite (the "MaaS Enterprise"),” the court documents say. “Through the Maas Enterprise, Defendants and their accomplices have victimized hundreds of thousands of innocent computer users, including many users of Microsoft's software and services.” ®

The Metropolitan Police Service (MPS) will start using static live facial recognition (LFR) cameras in London's West End and Soho by the end of this year following a six-month pilot in the south London borough of Croydon. Static LFR involves the police temporarily attaching cameras to lampposts or similar infrastructure, with the feeds monitored remotely and officers on the ground stopping people whom the technology matches to images on its watchlist. The MPS said that each of the 24 deployments in central Croydon between October 2025 and March 2026 used a bespoke watchlist created up to 24 hours in advance and deleted afterward. Civil liberties campaign group Big Brother Watch, which in April lost a High Court challenge to police use of LFR, said the force was rushing ahead with deployment before Parliament has passed legislation regulating the technology's use. "We are calling on the Met to stop this experiment until, at least, Parliament has spoken," Jack Coulson, the group's head of advocacy, said in a press release. "Policing by consent is a cultural inheritance we must protect. Permanent biometric surveillance of the public square is incompatible with that ideal." He highlighted the case of Alvi Choudhury, a Southampton man arrested and held for ten hours in January after a retrospective LFR system run by Thames Valley Police matched him to a crime committed in Milton Keynes, a city he had never visited. "It is predictable, given the technology's racial bias, that Mr Choudhury was confused for another Asian man," said Coulson. The MPS said that in Croydon more than 470,000 people walked past the LFR cameras, leading to 173 arrests and one false alert, which resulted in officers stopping someone without arresting them, realizing the mistake, and letting them go. The force added that one of those arrested, a registered sex offender who was communicating with a child under 16, was subsequently sentenced to two years in prison in May for breaching a sexual harm prevention order and making indecent images of children. MPS Commissioner Mark Rowley said on June 24 that the force planned to "significantly step up our use of technology to fundamentally change how we protect the public" through the use of live LFR, a city-wide emergency services drone network, and AI to analyze the footage from the capital's one million CCTV cameras. Rowley added that the force needs to spend more on technology but its budgets for doing so have been repeatedly cut, with spending of around £6,000 per person compared with budgets of more than double that at some government agencies. Earlier this month, the commissioner said the MPS would have to cut around 700 frontline posts after London's deputy mayor for policing and crime, Kaya Comer-Schwartz, refused to approve its plan to award a major contract to controversial US supplier Palantir. ®

Introduction

During our research of activity affecting a diplomatic organization in Indonesia, we uncovered a previously undocumented malware family that we have named SharkLoader. What initially appeared to be an isolated case quickly expanded into a broader campaign as we identified additional SharkLoader infections across multiple countries and sectors.

Our investigation revealed that SharkLoader serves as a loader designed to deploy Cobalt Strike Beacon on compromised systems. We observed the threat actor deploying SharkLoader through exploitation of internet-facing applications, including Microsoft Exchange, Microsoft SharePoint, and Openfire Server, as well as through malware-based delivery mechanisms.

Beyond the diplomatic entity in Indonesia, we identified related activity targeting government organizations in Taiwan, software development companies across multiple countries, and entities in other sectors located in Hong Kong, Lebanon, Syria, Colombia, North Macedonia, Nepal, Serbia, and more. The observed victimology suggests a campaign with broad geographic reach and a diverse target set rather than a narrow focus on a specific industry or region.

For now, we are tracking this activity as StrikeShark. Although the operators utilize several open-source post-compromise tools associated with Chinese-speaking developers, we have not identified direct code reuse, infrastructure overlap, or operational similarity to confidently attribute the activity to any known APT or cybercrime group. As a result, attribution remains preliminary and the campaign’s ultimate objectives are still under research.

Initial infection

Our analysis of SharkLoader intrusions indicates that the threat actor employs multiple methods to gain initial access to victim environments. During our investigation, we observed two primary infection vectors: the exploitation of vulnerabilities in internet-facing applications and the deployment of custom dropper samples, some of which were disguised as legitimate software.

Exploitation of public-facing applications

In the incident affecting an Indonesian diplomatic entity, the threat actor exploited Microsoft Exchange vulnerabilities, including CVE-2021-26855 (ProxyLogon), to gain access to the target environment. Similar activity was observed in Taiwan, where software development organizations were compromised through exploitation of Openfire (CVE-2023-32315). In a separate incident affecting a Colombian organization, the threat actor exploited a GeoServer instance vulnerable to CVE-2024-36401.

Beyond these incidents, we identified additional exploitation activity targeting vulnerabilities in multiple internet-facing enterprise applications and network appliances including those listed below:

Remote Code Execution (RCE)

• Apache Shiro: CVE-2016-4437
• Hikvision Products: CVE-2021-36260
• Microsoft SharePoint: CVE-2021-27076
• Zimbra Collaboration Suite: CVE-2022-27925
• Microsoft Exchange Server: CVE-2022-41082
• F5 BIG-IP system: CVE-2023-46747
• Fortinet FortiOS: CVE-2024-21762
• React Server Components: CVE-2025-55182

Authentication Bypass

• Fortinet FortiOS: CVE-2022-40684
• Cisco IOS XE Web UI: CVE-2023-20198

As of the time of writing this article, we haven’t obtained the exploits the attackers used. However, based on the vulnerabilities observed across multiple attacks, we assess with medium confidence that the threat actor primarily relies on publicly available proof-of-concept (PoC) exploits to gain initial access. All the vulnerabilities identified during our investigation have publicly available exploit code, including PoCs hosted on GitHub and other open-source platforms, suggesting the actor leverages existing offensive resources rather than develops custom exploit capabilities. The victim profile also indicates that the activity is largely opportunistic, affecting organizations across various industries, regions, and technology environments without a clear focus on a specific target set. Also, one of the IP addresses associated with the C2 domain was also observed conducting internet-wide scanning activity, potentially aimed at identifying and exploiting vulnerable internet-facing systems at scale.

Following exploitation, the attacker established persistence on compromised servers through the deployment of webshells. Although we were unable to recover the webshell files, a series of commands whose execution we observed in our telemetry along with the detection records of webshells strongly indicate their use for post-exploitation activities.

One of the earliest observed actions involved copying the legitimate Windows application SystemSettings.exe to a new location before executing it.

cd C:\Windows\ImmersiveControlPanel\ copy SystemSettings.exe C:\ProgramData\ cd C:\ProgramData\ SystemSettings.exe

This application was later abused as part of a DLL sideloading chain used to launch SharkLoader, which in this scenario was hidden in the malicious SystemSettings.dll library. We suspect that this DLL along with malicious encrypted files, which we’ll describe further, was uploaded through the webshell to the same directory as SystemSettings.exe.

In another case involving the exploitation of CVE-2021-27076, the threat actor launched SystemSettings.exe triggering the subsequent SharkLoader sideloading chain from different directories on the system, which suggests renewed operational activity in the victim environment. In some of the cases, they used security product vendor names as the directory names, allegedly to appear legitimate.

cd C:\ProgramData\KasperskyLab\ dir .\SystemSettings.exe cd %APPDATA% dir cd kasperskylab dir .\SystemSettings.exe

Dropper-based distribution

In several observed cases, the threat actor distributed SharkLoader through custom dropper executables masquerading as legitimate software installers or applications such as Google Update and Cisco AnyConnect. However, the exact delivery mechanism used to distribute these droppers remains unknown.

The observed dropper filenames include:

• GoogleUpdateStepup.exe
• AnyConnect-win-4.10.04071-predeploy-k9exe
• AutoUpdate.exe
• 319-pfd-8001-reva_traitement biologique_master.zip

In one of the samples we analyzed, the threat actor used a legitimate Cisco AnyConnect VPN installer as a lure. The custom dropper extracted zlib-compressed data embedded within its resource section, decompressed it into an MSI package, and wrote the file to %APPDATA%\reports\AnyConnect-win-4.msi. The MSI package was a legitimate Cisco AnyConnect VPN installer, which was subsequently executed via the ShellExecuteW API, making the user believe the custom dropper was a legitimate application.

While the Cisco AnyConnect installer was decompressed and executed, SharkLoader components were silently dropped into directories in %APPDATA% different from %APPDATA%\reports\ in the background, executing the malware loader once the installation process completes.

Malicious Cisco Secure Client installer

In addition to installer-themed lures, several SharkLoader droppers use decoy PDF documents to persuade victims to open the malicious file. However, not all samples employ this technique, as some droppers function solely as a delivery mechanism for SharkLoader without presenting any lure content.

Among the samples analyzed, most droppers write the decoy PDF to a subdirectory named aswerf within the %TEMP% directory, while others save the document directly to %TEMP%.

Analysing the sample shows the PDF files are stored within the dropper’s resource section under the resource name TELEMETRY and are compressed with zlib. Upon execution, the dropper extracts and decompresses the embedded PDF, writes it to disk using the same filename as the dropper executable but with a PDF extension, and launches it via cmd.exe /c to display the decoy document to the victim.

The following are examples of PDF documents extracted and displayed by the droppers during the deployment of SharkLoader.

Lure document 1. The document appears to be related to a biological treatment process and was produced by an engineering consultant

Lure Document 2. Translated title: Liquid Rocket Engine Design Program

In one dropper sample, discovered on a machine located in Lebanon (MD5: 1F65544978B8EA0E745E573B8EE9684B), the dropper extracts and decompresses SystemSettings.dll from zlib-compressed data embedded within the binary and writes it to %APPDATA%\xwreg. It also extracts and decompresses DscCoreR.mui and SyncRest.dat from resources named VAULTSVCD and UMRDPRDAT, respectively, and writes them to the same directory.

The dropper extracts SystemSettings.dll from the binary and retrieves encrypted components from the resource section

The dropper then copies the legitimate SystemSettings.exe application from C:\Windows\ImmersiveControlPanel to the target location to facilitate DLL sideloading. Across other SharkLoader dropper samples analyzed, the malware components were observed being written to either %APPDATA%\xwreg or %APPDATA%\xgdf.

SharkLoader installation

SharkLoader is composed of multiple components that work together to load and execute the final implant, a Cobalt Strike Beacon.

Filename Description SystemSettings.exe Legitimate Windows application abused for DLL side-loading of the
malicious DLL SystemSettings.dll. SystemSettings.dll Main malicious SharkLoader DLL responsible for the core loader functionality. DscCoreR.mui An encrypted module that contains an embedded Cobalt Strike Beacon and the MinHook library. This module loads SyncRes.dat, installs a couple of API hooks, and executes the Beacon directly in memory. SyncRes.dat An encrypted DLL that is used to install multiple API hooks.

While the majority of SharkLoader samples analyzed rely on the sideloading of SystemSettings.dll, other variants leverage alternative DLL side-loading targets, including msedge.dll, PrintDialog.dll, and miracastview.dll, each of them leveraging a corresponding legitimate application.

Across the different variants examined, the encrypted modules were also observed using a variety of filenames, including:

GameInputInboxs32.mui diagerr.xml NtfsLog.etl Ignored.Dat VistaCompat.nls

The SharkLoader execution flow is as follows:

SharkLoader infection chain observed in the StrikeShark campaign

In the dropper-based infections, after deploying all required SharkLoader components, the dropper creates two scheduled tasks through the Windows Task Scheduler COM interfaces. Task names:

• OneDrive Standalone Update Task-S-1-5-21-4165425321-4153752593-2322023643-1000
• MicrosoftUpdateTaskUserS-1-5-32-2456537112-101246289-228944324-1000

Both tasks are configured to execute the copied SystemSettings.exe from the malware’s working directory (for example, %APPDATA%\xwreg or %APPDATA%\xgdf), triggering the side-loading of the malicious SharkLoader DLL.

The first scheduled task uses a time-based trigger that executes every five minutes, providing long-term persistence.

The second task is configured to execute every second, likely to ensure immediate execution of SharkLoader following deployment.

After a delay of approximately 1.5 seconds, the dropper removes the second scheduled task by using the Task Scheduler COM interfaces, leaving the first task in place to maintain persistence on the system.

SharkLoader DLL – Main implant

For the detailed analysis of the infection chain, we’ll focus on the SharkLoader components deployed by a malicious dropper named 一种异常状况的截图（包括操作系统和输入法版本）.pdf.exe (MD5: 24FCEBDEECBA65004FDB0923763D74FD), which was identified in a campaign targeting a government entity in Taiwan.

Filename MD5 SystemSettings.exe D98F568496512E4F98670C61C97CB07A SystemSettings.dll AA3086BE652C8B20B0B29B2730D57119 DscCoreR.mui A514D1BB62D7916475946FE7C07AC0AA SyncRest.dat 9CBD560F820C95D7C38342CD558CB5C6 “PerfectDLL Hijacking” technique

Once the malicious DLL is loaded, SharkLoader implements a technique commonly referred to as “Perfect DLL Hijacking” and originally described by a security researcher named Elliot Killick on his blog. The purpose of this technique is to bypass the Windows loader lock and safely create a malicious thread via the CreateThread API without risking a deadlock.

According to Microsoft’s Dynamic-Link Library Best Practices, the Windows loader holds a synchronization object known as the “loader lock” while executing the DllMain function. This mechanism ensures that only one thread can perform DLL loading and initialization operations within a process at any given time. As a result, invoking APIs such as CreateThread or LoadLibrary from within DllMain can lead to deadlocks because the loader lock remains held throughout the execution of the function.

To avoid this issue, SharkLoader manipulates the process’s internal loader state to release the loader lock before invoking CreateThread from the DllMain execution path. By doing so, it attempts to execute its malicious code without triggering the loader-related deadlocks that can occur when threads are created while the loader lock remains held.

Implementation of the Perfect DLL Hijacking technique to bypass the Windows Loader Lock

Based on the code, SharkLoader first resolves the addresses of several undocumented loader structures within ntdll.dll, including:

1. LdrpLoaderLock: the critical section object used by the Windows loader to synchronize module loading and initialization operations
2. LdrpWorkInProgress: an internal loader state variable that tracks whether module initialization is currently in progress

After locating these structures, SharkLoader forcefully releases the loader lock by invoking LeaveCriticalSection on LdrpLoaderLock. It then decrements the value of LdrpWorkInProgress with InterlockedDecrement64, effectively marking the initialization process as complete.

Finally, the malware signals the loader completion event via SetEvent before creating a new thread to execute its malicious functionality. As a result, these actions manipulate the loader’s internal state and cause Windows to treat the DLL initialization process as having completed successfully. This allows SharkLoader to continue execution after forcefully releasing the loader lock, despite still operating from within the DllMain execution path.

Decryption and loading of >DscCoreR.mui

As shown in the previous section, the loader creates a new thread after escaping the Windows loader lock. This thread subsequently spawns a second thread responsible for decrypting and reflectively loading the encrypted file, DscCoreR.mui.

The routine first reads the encrypted file into memory and extracts the first 16 bytes to use as the Blowfish decryption key. It then initializes the Blowfish cipher by using custom P-array and S-box constants embedded in the loader and decrypts the file in ECB mode with the extracted key. Once decryption is complete, the resulting PE file is reflectively loaded into memory and executed without being written to disk.

Structure of the encrypted DscCoreR.mui file containing the 16-byte Blowfish key bytes followed by the encrypted PE bytes

The decrypted DscCoreR.mui file is a packed PE file with its MZ header removed, likely as an anti-analysis measure. After decryption, SharkLoader processes the PE image by parsing its headers, allocating memory for the image, mapping its sections, applying relocations, resolving imported functions, and setting the appropriate memory protections. Once the in-memory PE loading process is complete, the main loader, SystemSettings.dll, transfers execution to the entry point of the mapped image, which contains the packer stub.

The stub then unpacks the protected code, invokes the DLL’s DllMain function, and returns execution to SystemSettings.dll. Finally, SystemSettings.dll calls the exported function SetUserProcessPriorityBoost from the mapped DLL, triggering execution of the fully unpacked next-stage DLL.

DscCoreR.mui and SyncRes.dat DLLs

Within the decrypted and unpacked DscCoreR.mui code, the malware proceeds to load and decrypt a second encrypted file, SyncRes.dat, before reflectively loading the resulting DLL into memory.

The mapped DLL installs multiple API hooks by using Microsoft Detours, which will be discussed in the next section.

After mapping and loading SyncRes.dat for API hooks, the DscCoreR.mui performs installation of the Vectored Exception Handler (VEH) and then creates a thread in a suspended state that is later used to execute the Cobalt Strike Beacon shellcode. Additionally, to facilitate additional API hooks, it decompresses and loads the MinHook library and uses it to install hooks on the VirtualAlloc and Sleep APIs.

The DscCoreR.mui then decompresses the Cobalt Strike Beacon shellcode into the memory region associated with the suspended thread and then the suspended thread is resumed, resulting in execution of the beacon.

Decryption and loading of SyncRes.dat

To decrypt SyncRes.dat, the malware extracts a 16-byte AES-128 key and a 16-byte initialization vector (IV) directly from the file itself. The first 16 bytes of the file contain the AES key, while the subsequent 16 bytes contain the IV. The remaining file content consists of AES-encrypted data, which is decrypted using the extracted key and IV. Once decrypted, the resulting data reveals a PE image with its MZ header removed, similar to DscCoreR.mui.

Structure of the encrypted SyncRes.dat file showing the AES key, IV, and encrypted PE bytes

Similar to the decrypted DscCoreR.mui module, the decrypted SyncRes.dat file is also protected by an unknown custom packer. After decryption, the loader reflectively loads the PE image before transferring execution to the module’s entry point.

The entry point contains a packer stub responsible for unpacking the protected code in memory. Once the unpacking routine is complete, the malware invokes a specific exported function named StartEngineData, which serves as the primary execution routine of the third-stage DLL.

Before continuing with the DscCoreR.mui analysis, we will first discuss SyncRes.dat.

SyncRes.dat decrypted DLL: Multiple API hooks

The decrypted and unpacked SyncRes.dat DLL is primarily responsible for installing multiple Windows API hooks by using the Microsoft Detours library. After attaching all detour hooks, it calls DetourTransactionCommitEx to apply them in one commit.

The following table lists the hooked Windows APIs and their corresponding hook handler functions.

Hooked Windows APIs Detour function description CreateProcessA

• Saves all original CreateProcessA parameters for use in the parent process (PPID) spoofing routine.
• Creates a new thread that executes the process creation routine responsible for PPID spoofing.
  • Falls back to the original CreateProcessA if the thread creation fails.
• Identifies an svchost.exe process that has the same security context as the current SharkLoader process.
• Builds an extended startup attribute list to set the selected svchost.exe as the spoofed parent.
• Calls the original CreateProcessA with the modified parent attribute.

As a result, any new process created by the current process (primarily from the Cobalt Strike beacon) is spawned under svchost.exe instead of the current module process. CreateProcessW

• Saves all original CreateProcessW parameters for use in the PPID spoofing routine, which is executed through an APC-based mechanism rather than a dedicated thread compared to the CreateProcessA API hook.
• Schedules a delayed process creation (10 microseconds) through APC execution using CreateWaitableTimerW and SleepEx.
  • The timer callback performs the svchost.exe PPID spoofing logic, similar to the CreateProcessA spoofing routine.

As a result, new processes created via CreateProcessW by the current process (primarily from the Cobalt Strike beacon) are launched under svchost.exe through an APC-based execution mechanism OpenProcessToken

• Once hooked, the malware initializes jitasm to construct a direct syscall stub for NtOpenProcessToken at runtime.
• Invokes NtOpenProcessToken through the constructed direct syscall stub, redirecting the original API (OpenProcessToken) call flow.

AdjustTokenPrivileges

• Redirects the API call to a direct NtAdjustPrivilegesToken syscall stub constructed by jitasm.

OpenProcess

• Redirects the API call to a direct NtOpenProcess syscall stub constructed by jitasm.

WriteProcessMemory

• Redirects the API call to a direct NtWriteVirtualMemory syscall stub constructed by jitasm.

NtCreateUserProcess

• Redirects the API call to a direct NtCreateUserProcess syscall stub constructed by jitasm.

LoadLibraryA

• Redirects the API call to a function that resolves LdrLoadDll API using a ROR13-based API hashing algorithm.
• Uses the original parameters to invoke LdrLoadDll directly.
• If LdrLoadDll resolution or invocation fails, uses CreateTimerQueue and CreateTimerQueueTimer to schedule a 10-millisecond delayed execution of the original LoadLibraryA, with CreateEventW used for synchronization.

GetModuleHandleA

• Redirects the API call to a custom function that resolves the module base address through the following steps:
  • Enumerates loaded modules within the current process using CreateToolhelp32Snapshot, Module32FirstW, and Module32NextW.
  • Compares each enumerated module name with the module name provided in the API parameter.
  • Returns the module base address if a match is found.
• Falls back to the original GetModuleHandleA API if the custom resolution routine fails.

GetModuleHandleW

• Similar approach to the GetModuleHandleA API hooks above.

GetProcAddress

• The original GetProcAddress parameters are passed to the hook handler.
• The hook handler computes a Murmur32 hash of the requested function name.
• The hook handler parses the module’s PE structure and locates the export table.
• Each exported function name is hashed using the same Murmur32 algorithm and compared against the previously generated hash.
• If a hash match is found, the corresponding function address is returned. If no match is found, the call falls back to the original GetProcAddress.

LoadLibraryExA

• The hook handler redirects the API call to its original address. In short, the hooked LoadLibraryExA calls the original LoadLibraryExA function.

VirtualAllocEx

• Redirects the API call to a direct NtAllocateVirtualMemory syscall stub constructed by jitasm.

VirtualProtectEx

• Redirects the API call to a direct NtProtectVirtualMemory syscall stub constructed by jitasm.

VirtualProtect

• Redirects the API call to a direct NtProtectVirtualMemory syscall stub constructed by jitasm.

ResumeThread

• Redirects the API call to a direct NtResumeThread syscall stub constructed by jitasm.

GetThreadContext

• Redirects the API call to a direct NtGetContextThread syscall stub constructed by jitasm.

OpenThread

• Redirects the API call to a direct NtOpenThread syscall stub constructed by jitasm.

NtCreateThread

• Redirects the API call to a direct NtCreateThread syscall stub constructed by jitasm.

NtCreateThreadEx

• Redirects the API call to a direct NtCreateThreadEx syscall stub constructed by jitasm.

NtQueueApcThread

• Redirects the API call to a direct NtQueueApcThread syscall stub constructed by jitasm.

NtQueueApcThreadEx

• Redirects the API call to a direct NtQueueApcThreadEx syscall stub constructed by jitasm.

ExpandEnvironmentStringsA

• The detour redirects the API to a custom function that creates a new thread. That thread executes a routine that calls the ExpandEnvironmentStringsA API.

CreateFileMappingA

• The detour redirects the API call to a custom function that creates a new thread. Within the thread, it initializes thread-pool and timer objects, sets a threadpool timer for 10 ms and a waitable timer for 0.1 ms, then calls CreateFileMappingNumaA.
• If thread creation fails, CreateFileMappingNumaA is called directly without creating a thread.

MapViewOfFile

• The detour redirects the API call to a custom function that creates a new thread. The thread runs a similar thread-pool and timer setup to the previous function, resolves MapViewOfFileEx via GetProcAddress, calls it with zeroed arguments, and stores the return value.

UnmapViewOfFile

• The detour redirects the API to a function that tries to run the unmap (same API) in a new thread.
• The thread creates an event and timer queue, schedules a callback after 10 ms to call UnmapViewOfFile and signal the event, then waits and cleans up.
• If thread creation fails, it calls UnmapViewOfFile directly.

NtMapViewOfSectionEx

• Redirects the API call to a direct NtMapViewOfSectionEx syscall stub constructed by jitasm.

NtCreateNamedPipeFile

• Redirects the API call to a direct NtCreateNamedPipeFile syscall stub constructed by jitasm.

NtReadFile

• Redirects the API call to a direct NtReadFile syscall stub constructed by jitasm.

NtWriteFile

• Redirects the API call to a direct NtWriteFile syscall stub constructed by jitasm.

EtwEventWrite

• The detour redirects EtwEventWrite to a stub that always returns 1, which prevents ETW logging.

EventWriteEx

• The detour redirects EventWriteEx to a function that always returns 0, which prevents ETW logging.

EventWrite

• The detour redirects EventWrite to a function that always returns 0, which prevents ETW logging.

Upon completing the installation of API hooks via the decrypted SyncRes.dat, the DscCoreR.mui DLL proceeds with the remaining functions, which are discussed below.

VEH registration and access violation handling

Following the installation of the API hooks, the malware registers a Vectored Exception Handler (VEH) to monitor exceptions generated during runtime. The handler specifically checks for access violation exceptions (0xC0000005). When such an exception occurs, it retrieves the faulting memory address from the exception record and calls VirtualProtect to restore read, write, and execute (RWX) permissions to the corresponding memory page before resuming execution.

During our analysis, no access violations were observed. It is possible that this mechanism is intended to handle access violations that may occur under specific runtime conditions.

Thread creation for Cobalt Strike Beacon execution

The malware creates a new thread in a suspended state that is intended to execute the Cobalt Strike Beacon shellcode. The thread entry point is configured to point to a memory buffer that will later contain the beacon shellcode.

At this stage, the buffer does not yet contain the actual Cobalt Strike Beacon shellcode. Instead, the thread is created in a suspended state so that the malware can prepare and inject the shellcode into the buffer before execution. Once the beacon payload has been written into the buffer, the malware resumes the suspended thread using the ResumeThread API, which triggers the execution of the Cobalt Strike beacon.

MinHook DLL, API hooking, and Cobalt Strike beacon

After creating the suspended thread for beacon execution, the malware decompresses a zlib-compressed MinHook PE file embedded within DscCoreR.mui. The MinHook library is used to install API hooks for the VirtualAlloc and Sleep functions. Once the MinHook DLL is decompressed and loaded into memory, the malware resolves the exported functions MH_Initialize and MH_CreateHook, which are then used to install hooks on the VirtualAlloc and Sleep APIs.

After the hooks are installed, the malware invokes a function that decompresses a zlib-compressed Cobalt Strike Beacon shellcode embedded within the malware. The function first decompresses the shellcode into a temporary buffer and then allocates executable memory using VirtualAlloc with RWX permissions. The decompressed beacon is subsequently copied into the allocated memory region.

Because the VirtualAlloc API has already been hooked at this stage, the hook handler captures the address and size of the allocated memory used to store the beacon shellcode. The hook records the addresses and sizes of the first three successful memory allocations and stores these values in global variables to track specific memory regions allocated during execution. These tracked regions are associated with memory buffers used by the Cobalt Strike Beacon during runtime.

The second hook, on the Sleep API, is used when Cobalt Strike Beacon calls Sleep, such as during beacon sleep intervals. It temporarily modifies the memory protection of the tracked allocation regions by using VirtualProtect, changing their protection to PAGE_READWRITE (RW) before invoking the original Sleep function. After the sleep period ends, the malware restores the memory protection of those regions to PAGE_EXECUTE_READWRITE (RWX). This behavior suggests that the malware developer implemented this mechanism to evade memory scanning techniques that identify executable (RWX) code regions in memory.

Finally, after the API hooks are installed and the Cobalt Strike Beacon shellcode has been written to the thread buffer, the malware calls the ResumeThread API to resume the suspended thread and begin execution of the beacon.

Persistence mechanism

While the analyzed SharkLoader implant does not contain a built-in persistence mechanism especially when it comes to cases when it is dropped after the exploitation of a public-facing application, our investigations revealed that the threat actor employs several techniques to maintain access to compromised systems.

Registry Run key: In the incident that affected an organization in Hong Kong, the attacker manually created a registry Run key to launch SystemSettings.exe upon user logon. The following command was used:

reg add HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v "MFUpdate" /t REG_SZ /d "$appdata\Identities\SystemSettings.exe" /f

This technique allows the malware to automatically execute whenever the user logs in, ensuring persistent access.

Scheduled task: In the separate compromise that affected a diplomatic government entity in Indonesia, the attacker established persistence through a scheduled task configured to execute SharkLoader daily. The task, named "\Microsoft\Windows\Edge\Edgeupdate", was configured to run C:\ADriveLogs_Logs\SystemSettings.exe by using the following command:

Schtasks /create /s /u "" /p "" /ru "SYSTEM" /tn "\Microsoft\Windows\Edge\Edgeupdate" /sc DAILY /tr "C:\ADriveLogs_Logs\SystemSettings.exe /F"

Running the task with SYSTEM privileges ensures that SharkLoader executes even if no user is logged in.

Post-compromise activity

Following initial compromise and persistence, the attacker engaged in extensive reconnaissance and credential theft activities.

System information enumeration: The attacker initially gathered basic system information by using the following commands:

systeminfo ipconfig /all tasklist /svc

Post-exploitation tools: Our analysis revealed the use of several third-party post-exploitation tools, most of which are open-source and developed by Chinese-speaking developers. These tools included:

Tool name Description FScan Network scanner tool with vulnerability
exploitation modules Searchall Sensitive information search tool Pillager Information gathering tool

We also detected the use of SharpGPOAbuse by the threat actor, a tool designed to modify Group Policy Objects within Active Directory environments.

Active Directory enumeration: In the compromise affecting a diplomatic government entity in Indonesia, the attacker used both Cobalt Strike and a webshell to enumerate the internal Active Directory environment. They executed a series of commands to gather information about the network, users, and groups:

• Network information:
  ping -n netstat -ano arp -a net share
• User and group information:
  query user nslookup quser net group /domain
• Specific group membership:
  powershell "Get-ADGroupMember -Identity "" -Recursive | Select-Object Name, ObjectClass" dsquery group -name "" | dsget group -members -expand | dsget user -samid -display -email" powershell "Get-ADGroupMember -Identity "" -Recursive | Where-Object { $_.ObjectClass -eq "computer" } | Select-Object Name, SamAccountName" powershell -exec bypass -c "Get-ADUser -Filter * -Prop * | select sAMAccountName net group "Domain Controllers" /domain net group "Enterprise Admins" /domain net group "Organization Management" /domain net group "domain admins" /domain
• Process enumeration:
  tasklist /SVC | findstr $selfname.exe
• Directory listing:

dir \\c$ dir \\c$\inetpub dir \\c$\inetpub\custerr dir \\c$\inetpub\wwwroot\

Credential dumping: The attacker also attempted to dump credentials from the compromised machine by targeting both the LSASS process and the NTDS database file. The following commands were observed:

ntdsutil "ac i ntds" "ifm" "create full $temp" q q Procdump64.exe -accepteula -ma lsass.exe $temp\lsass.dmp

Dumping the LSASS process allows the attacker to extract in-memory credentials, while accessing the NTDS database enables retrieval of Active Directory account password hashes. This combination of techniques allows the attacker to obtain privileged credentials for lateral movement, privilege escalation, and deeper compromise.

Victimology

The victimology observed in this campaign shows a combination of strategic and opportunistic characteristics. Confirmed victims include government-related entities, such as the ministry in Taiwan and the diplomatic organization in Indonesia, as well as software development companies in Taiwan, Lebanon, and Syria. Additional affected organizations were identified in Hong Kong, Colombia, Macedonia, Nepal, and Serbia.

Targeting of government and software development organizations may indicate a cyber-espionage objective, although our confidence remains low due to the limited post-compromise activity observed, which primarily consisted of credential access, system reconnaissance, and lateral movement. The compromise of government and software development organizations could indicate an interest in gathering political intelligence or intellectual property.

At the same time, the use of SharkLoader and Cobalt Strike, alongside the exploitation of public-facing applications and malicious installers and droppers, suggests the attacker may also be opportunistically targeting vulnerable systems. The absence of clear evidence of data exfiltration thus far does not exclude this possibility, as Cobalt Strike’s file operation and data exfiltration modules could be employed at a later stage.

Although the full scope of the campaign is not yet known, the combination of targeted and opportunistic activity suggests it should continue to be closely monitored.

Attribution

Our investigation reveals no code or infrastructure overlap linking SharkLoader to any existing threat actor at this time. The TTPs employed during the operation also do not align with those of known actors.

However, analysis of the post-exploitation open-source tools used during the campaign revealed that several reconnaissance tools, including FScan, Searchall, and Pillager, were developed by individuals identified as Chinese speaking developers on GitHub.

We assess StrikeShark to be a Chinese-speaking threat actor with low confidence. This assessment is based on limited indicators and should be considered preliminary. Further investigation is required to characterize this cluster more fully, and the possibility remains that other actors may also be utilizing these tools.

Conclusion

Our investigation discovered a previously undocumented intrusion cluster that we are tracking as StrikeShark. The StrikeShark campaign represents a sophisticated malware threat to entities worldwide. The use of SharkLoader to deploy Cobalt Strike, coupled with API hook installation to evade detection, demonstrates a significant level of technical expertise. The campaign’s broad targeting across sectors and geographic regions suggests a potential focus on espionage or information gathering. While the precise objectives remain under investigation, the combination of targeting government entities and software developers warrants heightened vigilance.

Given that our visibility is limited to incidents observed through Kaspersky telemetry, we suspect the actual number of compromises may be significantly higher and extend beyond these victims as the threat actor actively used several exploitations of public facing application.

Indicators of compromise

Additional information about this activity, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. If you are interested, please contact [email protected].

C559CC68986933200FD5D9E4388E2F58                    Installer
B3352B42432DEDC4A519F011DC8B5D5A                  Dropper
24FCEBDEECBA65004FDB0923763D74FD                  Dropper
9C872A0D5D5A38950E8B9AC9B488BE3F                  SharkLoader DLL
AA3086BE652C8B20B0B29B2730D57119                   SharkLoader DLL
A514D1BB62D7916475946FE7C07AC0AA                  Encrypted file
9CBD560F820C95D7C38342CD558CB5C6                  Encrypted file
connect-microsoft[.]com
ms-record[.]com
ms-record[.]top
ms-tray[.]top

Japanese telco KDDI has messed up by allowing an attacker to access systems powering an email service it manages for itself and other local ISPs, and which stores info on up to 14.2 million users. The company yesterday posted a confession [PDF] that it detected unauthorized access to the email system it offers to third-party customers on June 17th. Machine translation of the confession suggests that KDDI investigated the situation and found attackers exploited a vulnerability in third-party software used on the email service, without claiming that vuln was a zero-day it had no chance of defending or an explanation of why it was running vulnerable software. There’s some good news because KDDI was able to prevent further intrusion on the same day it noticed the attack, and says it has bolstered its defences to prevent future intrusions. But the carrier also fears that up to 14.2 million email addresses and passwords may have leaked and therefore warned that third parties may have obtained personal data. Thankfully, the company had hashed and encrypted the passwords – so users only have to fear phishing and identity theft, instead of something nastier. However, some of the data KDDI thinks may have leaked pertains to dormant accounts or others that users cancelled, meaning some potential victims will be hard to contact if the attackers have indeed stolen data. KDDI is one user of the hacked platform, and also provides it to Japanese ISPs STNet, JCOM, Chubu Telecommunications Co., Nifty Corporation, and BIGLOBE. Those companies now get to explain KDDI’s failure to their own customers, and perhaps also have the chance to revisit any other outsourcing deals with the carrier. Others who rely on KDDI to provide them with various services also get to ask the company some stern questions about whether its other platforms are secure. The carrier, meanwhile, says it’s informed the relevant authorities of the situation, but is yet to complete an investigation so remains unaware of the full extent of the mess. ®

Sometimes it takes a while to detect a vuln. A 29-year-old, Heartbleed-style vulnerability in Squid, a popular open-source caching proxy server, silently leaked users' plaintext HTTP requests and potentially revealed sensitive data, including credentials and session tokens, for decades - until AI (and a few humans) saved the day. A security researcher and Mythos Preview found the flaw and reported it to project maintainers, who fixed the code earlier this month. Squid is widely used by large corporations, schools, and internet service providers to cache, filter, and monitor network traffic, and Calif.io researcher Lam Jun Rong said he came across the open source proxy while attempting to connect to the internet on a flight. “As you might expect, the version of Squid deployed on that plane was released nearly 10 years ago and is affected by the vulnerability I'm about to share with you,” Rong wrote in a blog post about the bug, which he dubbed Squidbleed and investigated with help from Anthropic's Claude Mythos Preview. Rong reported the bug, tracked as CVE-2026-47729, to Squid’s maintainers back in April, and it’s fixed in Squid v7.6, released June 8. However, we learned after initial publication of this article that another researcher had also found the bug, even earlier. Aisle security researcher Pavel Kohout found and reported the vulnerability on March 4, before Calif's initial April report. The Reg readers may remember Calif from their earlier HTTP/2 Bomb research, uncovered by OpenAI’s Codex agent, and the AI bug-finding firm also collaborated with OpenAI on its Patch the Planet initiative, announced on Monday. According to Rong, Squidbleed leaks internal memory from every version of Squid in its default configuration with two conditions. First, Squid has to be able to read and inspect the network traffic, so it must be handling cleartext HTTP (not HTTPS) or be deployed in TLS-terminating setups. Additionally, the proxy must be allowed to reach an attacker-controlled FTP (File Transfer Protocol) server via TCP port 21. FTP is an outdated protocol for moving files between machines, and Squid supports it - which is where the problem lies. The bug exists in Squid's FTP directory listing parser, and it was injected into the open source code as a commit (bb97dd37a) created in 1997 to support old NetWare servers. NetWare is a discontinued network operating system that was popular in the 1980s and 1990s, providing file and print services across local area networks before Windows and Linux servers became dominant. NetWare FTP servers also added extra whitespace between the modification timestamp and the filename, compared to most other FTP servers that just used a single space. The 1997 commit fixed this NetWare issue by instructing the code to skip the extra whitespace using this loop: while (strchr(w_space, *copyFrom)) ++copyFrom;. As Mythos Preview discovered, if an attacker's FTP server doesn't provide a filename after the modification timestamp, copyFrom points to the terminating NUL character at the end of the string. “strchr treats that terminating NUL as part of the string it searches, so it returns a pointer instead of NULL, and the loop never stops,” Rong explains. “It walks off the end of the buffer, and xstrdup copies whatever follows back to the attacker as a filename.” This results in a heap overread and can leak HTTP requests that often contain passwords or API keys, and Rong demonstrated this exploit in a proof of concept. “The patch is simple: check for the null terminator before calling strchr,” Rong wrote. If you use Squid, make sure to download the June release to fix this flaw. Also, as Rong suggests, you should disable FTP unless there’s a “specific, unusual need for it.” Chromium-based browsers stopped supporting FTP years ago and for good reason. This means “most organizations running Squid are getting close to zero legitimate FTP traffic,” the security sleuth noted. “Turning it off removes this entire attack surface for free.”® Updated on June 25 to show that another researcher had found this bug first.

The leaders of intelligence agencies from the Five Eyes nations – Australia, Canada, New Zealand, the USA and the UK – have together issued strongly worded advice calling for leaders to nail cybersecurity basics or fall victim to ruinous AI-powered attacks. “The rapid pace of frontier AI development means cyber risk assumptions can become outdated in months, not years,” the advice warns, and calls for organizations to take rapid action to ensure their defenses remain potent. “While AI will help us improve cyber defence over time, it also accelerates the speed, scale, and sophistication of cyber threats,” the advice adds. “Frontier AI models are anticipated to exceed current industry expectations, fundamentally transforming both offensive and defensive cyber capabilities. The timeline is not years, it is months.” After all that scary stuff, the spook bosses offer some antidote: “Cyber resilience is integral to advancing business continuity, market confidence, and long-term value.” And how might one achieve that resilience? The Five Eyes have four suggestions: Understand and assess risk, readiness and accountability Prioritize foundational cyber security practices and controls Empower cyber leaders with authority and resources Stay actively engaged as threats and guidance evolve “Cyber risk can no longer be treated as a purely technical issue,” the advice points out. “This is a core business risk and leadership responsibility,” because breaches are inevitable and “Breaches will occur. Preparedness helps you contain them quickly and prevent escalation into major operational and financial crises.” The intelligence chiefs therefore want organizations to test their cyber resilience rigs. “It is not enough to have controls,” they write. “Leaders must be confident those controls will perform during a real incident. This requires reassessing long-standing trade-offs and using AI deliberately to strengthen defence – not just improve efficiency.” That last sentence is a rare moment of optimism in the advice and precedes a section in which the intelligence bosses observe “Organizations that integrate AI tools into their security operations can detect vulnerabilities earlier, improve software quality, monitor unusual behaviour, and respond faster to incidents – reducing both the cost and impact of incidents.” Readers of The Register might find this advice a little quaint given that infosec vendors have for years blathered on about the need for boards and bosses to take cyber seriously. It’s also been a couple of years since it became apparent that generative and agentic AI can fuel new and unusually potent cyber-attacks. Interest in that idea spiked in the eleven weeks since Anthropic revealed the existence of its powerful flaw-finding Mythos model and hid it behind a regwall lest criminals use it to swiftly slice holes in important software. The Five Eyes bosses address their advice to “leaders” – presumably bosses of substantial organizations – who may not have watched the Mythos mess unfurl while they worried about a global energy crisis kicking holes in their supply chains. The good news is that the spy bosses don’t think leaders need to learn a lot to cope with the advent of AI, as their advice suggests five practical actions they rate as “not new,” but “now urgent to reduce not only technical risk, but also operational, financial and reputational exposure.” For the record, those actions are: 1. Reduce your attack surface: Limit unnecessary system access and external connectivity. Challenge whether systems need to be exposed at all and isolate those that do not. 2. Accelerate patching processes: AI is shortening the time between vulnerability discovery and exploitation. Delays in patching increase risk, especially for operational systems with long update cycles. Prioritize security updates accordingly to manage risks. 3. Address legacy systems: Unsupported systems are easy targets. They are not just technical debt, they are strategic liabilities. 4. Review and strengthen identity and access controls: Limit who can access critical systems. Enforce strong authentication and regularly review permissions. 5. Prepare for incidents before they happen: Test response plans, train and prepare teams, and assume breaches will occur. Focus on fast containment and recovery. Take us, and this, to your leaders, dear readers. ®

The JavaScript development ecosystem may be a security nightmare, but it's also ripe for improvement. One such tool is the CVE Lite CLI, a free open source dependency scanner that helps reduce the risk of software supply chain attacks. It runs locally and provides actionable vulnerability fixes, if any are available. The tool, endorsed by OWASP, has recently been updated to include override auditing, which has the potential to avert transitive dependency vulnerabilities such as the March 2022 node-ipc package incident. The Shai-hulud software supply chain attacks that have been vexing security professionals for the past few months underscore how common it has become for threat actors to target the developer ecosystem, including CI/CD, package registries, and developer tooling. Software developers can reduce their risk by making sure the dependencies in their apps are up to date and free of known vulnerabilities, but that's more difficult than it should be. It's generally apparent when a particular library or module relies on a vulnerable dependency. But there isn't necessarily an available fix or clear remediation path. Modern JavaScript applications, like many other programming languages, allow developers to incorporate pre-existing solutions to particular problems in the form of packages – modular code that can be imported to implement particular functionality. These packages commonly depend on other packages, which is why they're known as dependencies. And these dependencies in turn may also depend on still more packages, referred to as transitive or indirect dependencies. A common security scenario goes something like this: A developer creates an app using some application framework. The app includes a dependency on "Package A", which itself relies on "Package B" – the transitive or indirect dependency in this situation. If the maintainers of "Package B" have deployed a patch addressing a reported CVE, but the maintainers of "Package A" haven't gotten around to incorporating that change into their code, apps incorporating "Package A" may be vulnerable to attack. Among other possible responses, affected developers may choose to create an override to replace the outdated, vulnerable version of "Package B," a configuration entry that can be removed once "Package A" gets repaired. But Sonu Kapoor, creator of CVE Lite CLI, explained to The Register that overrides represent a legitimate security tool but have limitations. "When a transitive dependency has a CVE and the upstream maintainer hasn't shipped a fix yet, you pin it via npm overrides, pnpm overrides, or Yarn resolutions," Kapoor explained in an email. "Once the vulnerability is addressed and CI passes, you move on. The problem is what happens after that." Kapoor recently added an override auditing tool to the CLI. When he scanned four popular JavaScript open source projects, he found that three of the four had broken overrides. "Cal.com has 90 override entries and 11 that are silently doing nothing," he said. "Jest has an override for its own package name pointing at nothing in the resolved tree. NoCoDB has entries using wildcard patterns that never matched any path in the graph. Next.js was the only clean one with zero findings, which tells me the tool is finding a real pattern, not noise." This can be dangerous, he said, when a project migrates between package managers (e.g. npm to pnpm) that looks for overrides in a different location. "npm reads from overrides, pnpm from pnpm.overrides, Yarn from resolutions," he explained. "When a team migrates package managers and forgets to move their security pins, the package manager silently ignores them. No error, no warning, the vulnerable package ships unconstrained." Kapoor said that AI coding assistants commonly advise developers to add override entries when asked to fix a transitive dependency vulnerability. "That advice is correct at the moment," he said. "None of them ever tell the developer to come back and verify the entry still works." CVE Lite CLI, Kapoor said, does not recommend overrides as the way to properly address a vulnerable dependency. "Overrides look like a security fix in package.json, but routinely outlive their purpose – they can point at packages no longer in the dependency tree, apply to the wrong package manager entirely, or shift to an unintended version on every install," he said. "The override hygiene feature exists precisely because of this failure mode: teams add an override to address a CVE, move on, and years later, the override does nothing while they still believe they're protected." ®