Look What You Made Us Patch: 2025 Zero-Days in Review

Written by: Casey Charrier, James Sadowski, Zander Work, Clement Lecigne, Benoît Sevens, Fred Plan

---

Executive Summary

Google Threat Intelligence Group (GTIG) tracked 90 zero-day vulnerabilities exploited in-the-wild in 2025. Although that volume of zero-days is lower than the record high observed in 2023 (100), it is higher than 2024’s count (78) and remained within the 60–100 range established over the previous four years, indicating a trend toward stabilization at these levels.

In 2025, we continued to observe the structural shift, first identified in 2024, toward increased enterprise exploitation. Both the raw number (43) and proportion (48%) of vulnerabilities impacting enterprise technologies reached all-time highs, accounting for almost 50% of total zero-days exploited in 2025. We observed a sustained decrease in detected browser-based exploitation, which fell to historical lows, while seeing increased abuse of operating system vulnerabilities.

State-sponsored espionage groups continue to prioritize edge devices and security appliances as prime entry points into victim networks, with just over half of attributed zero-day exploitation by these groups focused on these technologies. Commercial surveillance vendors (CSVs) maintained an interest in mobile and browser exploitation, adapting and expanding their exploit chains to bypass more recently implemented security boundaries and other mobile security improvements. Multiple intrusions linked to BRICKSTORM malware deployment demonstrated a range of objectives, but the targeting of technology companies demonstrated the potential theft of valuable IP to further the development of zero-day exploits.

Key Takeaways

1. Complexity drives higher mobile vulnerability counts.Mobile zero-day discovery counts fluctuated over the last three years, dropping from 17 in 2023 to 9 in 2024, before rebounding to 15 in 2025. As vendor mitigations evolve and increasingly prevent more simplistic exploitation, threat actors have been forced to expand or adjust their techniques. In some cases, attackers have increased the number of chained vulnerabilities to reach desired levels of access within highly protected components. Conversely, threat actors have also managed successful exploitation with fewer or singular bugs by targeting lower levels of access within a single capability, such as an application or service.
2. Enterprise software and edge devices remain prime targets.Marking a new high, 48% of 2025’s zero-days targeted enterprise-grade technology. Increased exploitation of security and networking devices highlights the critical risk that can be posed by trusted edge infrastructure, while targeting of enterprise software exhibits the value of highly interconnected platforms that provide privileged access across networks and data assets. Networking and security appliances continued to be highly targeted, by a variety of threat actors, to gain initial access.
3. Commercial surveillance vendors (CSVs) further reduce barriers to zero-day access. For the first time since we began tracking zero-day exploitation, we attributed more zero-days to CSVs than to traditional state-sponsored cyber espionage groups. This illustrates the expansion of access to zero-day exploitation via these vendors to a wider array of customers than ever before.
4. People’s Republic of China (PRC)-nexus cyber espionage groups continue to dominate traditional state-sponsored espionage zero-day exploitation. Consistent with the trend we have observed for nearly a decade, in comparison to other state sponsors, PRC-nexus groups remained the most prolific users of zero-day vulnerabilities in 2025. These groups, such as UNC5221 and UNC3886, continued to focus heavily on security appliances and edge devices to maintain persistent access to strategic targets.
5. Zero-day exploitation by financially motivated threat groups ties previous high. In 2025, we attributed the exploitation of 9 zero-days to confirmed or likely financially motivated threat groups. This nearly matches the total volume of 2023 and represents a higher proportion of all attributed vulnerabilities in 2025. 

2026 Zero-Day Forecast

Targets and Techniques Continue to Expand

As certain vendors continue to drive improvements that have made vulnerability exploitation more difficult, particularly in the browser and mobile space, adversaries will continue to adapt with more expansive techniques and diverse targets. Enterprise exploitation will continue to be further enabled by the breadth of applications used across infrastructure. Increased numbers of software, devices, and applications expand attack surfaces, with successful exploitation requiring only a single point of failure to achieve a breach.

AI Changes the Game

We anticipate that AI will accelerate the ongoing race between attackers and defenders in 2026 creating a more dynamic threat environment. We expect adversaries will utilize AI to automate and scale attacks by accelerating reconnaissance, vulnerability discovery, and exploit development. Reducing the time required for these phases will place further pressure on defenders to better detect and respond to zero-day exploitation. At the same time, AI will empower defenders to harness tools like agentic solutions to enhance security operations. AI agents can proactively discover and help patch previously unknown security flaws, enabling vendors to neutralize vulnerabilities before exploitation. 

Using Access for Research

A BRICKSTORM malware campaign in 2025, attributed to PRC-nexus espionage operators, may indicate a new paradigm for zero-day exploitation where data theft has the potential to enable long-term zero-day development. Instead of just exfiltrating sensitive client data, the threat actors targeted intellectual property from the victim companies, potentially including source code and proprietary development documents. This IP could be used to discover new vulnerabilities in the vendor's software, not only posing a threat to the victims themselves but also to victims’ downstream customers.

Scope

This report describes what Google Threat Intelligence Group (GTIG) knows about zero-day exploitation in 2025. GTIG defines a zero-day as a vulnerability that was maliciously exploited in the wild before a patch was made publicly available. The following analysis leverages original research conducted by GTIG combined with reliable open-source reporting, though we cannot independently confirm the reports of every source. 

Research in this space is dynamic and the numbers may adjust due to the ongoing discovery of past incidents. Our analysis represents exploitation tracked by GTIG but may not reflect all zero-day exploitation. The numbers presented here reflect our best understanding of current data, and we note that all zero-days included in our 2025 dataset have patches available. GTIG acknowledges that the trends observed and discussed in this report are based on detected and disclosed zero-days, with a cutoff date of Dec. 31, 2025. 

A Numerical Analysis

Figure 1: Zero-days by year

GTIG tracked 90 vulnerabilities that were disclosed in 2025 and exploited as zero-days. This number is consistent with a consolidating upward trend that we have observed over the last five years; the total annual volume of zero-days has fluctuated within a 60-100 range over this time period, but has remained elevated compared to pre-2021 levels. As certain categories of exploitation shift over time, whether due to vendor mitigations or newer high-value opportunities, total zero-day counts continue to appear within an expected range, rather than seeing drastic overall decreases or increases.

Enterprise Exploitation Expands Further in 2025

Figure 2: 2025 zero-days in end-user vs enterprise products

Enterprise Technologies

We identified 43 (48%) zero-days in enterprise software and appliances in 2025, up from 36 (46%) in 2024. This consistent proportion underscores the shift toward enterprise infrastructure as a structural change in the threat landscape, reflecting the value of tools that enable privilege escalation, high-level access, and broad scale of impact.

• Security & Networking: These vulnerabilities made up about half (21) of the enterprise-related zero-days in 2025, remaining a prominent target for achieving code execution and unauthorized access via privileged infrastructure components. A lack of input validation and incomplete authorization processes were common flaws within these products, demonstrating how basic systemic failures continue to persist, but are fixable with proper implementation standards and approaches. Edge devices–often including security and networking devices–sit at the perimeter of an organization's infrastructure and remain high value targets. The absence of EDR technology on most edge devices, like routers, switches, and security appliances, can create a blind spot for defenders, making it an ideal attack surface. This limitation can hinder the ability to detect anomalies or gather host-based evidence once these devices are compromised. While 14 zero-days in 2025 were identified as affecting edge devices, this figure likely underrepresents the true scale of activity due to inhibited detection capabilities.
• Enterprise Software: High-profile exploitation of enterprise tools and virtualization technologies demonstrates that attackers are deeply embedding themselves in critical business infrastructure. Threat actors continue to pursue the most vulnerable and exposed assets to work around mitigations that may exist in specific areas of or products within an infrastructure.

End User Platforms and Products

In 2025, 52% (47) of the tracked zero-days were used to exploit end-user platforms and products.

• Operating Systems (OSs): OSs, including both desktop and mobile, were the most exploited product category in 2025, accounting for 44% (39) of all zero-days. This is a rise from previous years when comparing both raw numbers (31 in 2024, and 33 in 2023) and proportions of total zero-day exploitation (40% in 2024 and 33% in 2023). Desktop OS zero-days have fluctuated between 16 and 23 annually while maintaining a gradual upward trajectory, illustrating the foundational role of these platforms and the massive scale of effect permitted by OS-level exploitation.

• Mobile Devices: Mobile OS exploitation in particular saw a notable increase, with a total of 15 zero-days in 2025 compared to the 9 identified in 2024. Given that we observed 17 mobile-related zero-days in 2023, the following factors likely accounted for this temporary decline and the subsequent resurgence in activity:

• Multiple exploit chains discovered in 2025 included three or more vulnerabilities, inflating the number of individual vulnerabilities required to achieve a single objective.

• Threat researchers discovered more complete exploit chains in 2025 than have been found in the past, when sometimes only partial chains or a single vulnerability was identified and could be accounted for.

• Threat actors, and CSVs in particular, have found novel techniques to bypass new security boundary implementations.

• Browsers: Browsers accounted for less than 10% of 2025 zero-day exploitation, a marked decrease from the browser-heavy years of 2021-2022. This suggests that browser hardening measures are working. However, we also assess that attackers’ operational security has improved and therefore made their actions more difficult to observe and track, potentially reducing the volume of observed exploitation in this space.

Exploitation by Vendor

Figure 3: 2025 zero-day exploitation by vendor

2025’s exploited vendors followed the same pattern we observed last year, with big tech experiencing the most zero-day exploitation and security vendors following directly behind. Big tech companies continue to dominate the user base for consumer products, making them prime targets for exploitation, particularly in desktop OSs, browsers and mobile systems. Cisco and Fortinet remain commonly targeted networking and security vendors, while Ivanti and VMware continue to see exploitation that reflects the high value threat actors place on VPNs and virtualization platforms.

We observed 20 vendors who were exploited by just one zero-day each, further demonstrating threat actors’ success in targeting varying vendors and products to find successful footholds in desired targets.

Types of Exploited Vulnerabilities

As observed in prior years, zero-day exploitation was primarily used to achieve remote code execution, followed by gaining privilege escalation. These were especially common consequences in observed exploitation of big tech and security vendors. Both code execution and unauthorized access were common goals of network and edge infrastructure exploitation, displaying the advantage of exploiting high-privilege assets with widespread reach across systems and networks.

2025 saw an array of both structural design flaws and pervasive implementation issues, exemplifying the omnipresence of known, yet prolific, problems. 

• Injection & Deserialization: Command injection and deserialization were critical vectors in the enterprise space. These types of vulnerabilities often allow for reliable remote code execution (RCE) without the complexity of memory corruption exploits. SQL and command injection vulnerabilities were common in web-facing enterprise appliances, providing rudimentary avenues for initial access.
• Memory Corruption: Threat actors continued to rely on memory corruption, with memory safety issues (particularly use-after-free [UAF] and out-of-bounds write) accounting for roughly 35% of the vulnerabilities. UAF weaknesses remained a top vector for user-centered products like browsers and OS kernels.
• Access Control: The prevalence of authentication and authorization bypass vulnerabilities highlights the difficulty edge devices face in securing both the network perimeter and their own administrative interfaces.
• Logic and Design Flaws: Frequently exploited in enterprise appliances, these issues represent fundamental architectural weaknesses where the system’s intended logic or design is inherently insecure. Because the software is behaving as designed, these flaws are harder for vendors to detect.

Who Is Driving Exploitation

Figure 4: Attributed 2025 zero-day exploitation

Commercial Surveillance Vendor Exploitation Grows

For the first time since we started tracking zero-day exploitation, we attributed more exploitation to CSVs than to traditional state-sponsored cyber espionage groups. Despite these actors’ increased focus on operational security that likely hinders discovery, this continues to reflect a trend we began to observe over the last several years–a growing proportion of zero-day exploitation is conducted by CSVs and/or their customers, demonstrating a slow but sure movement in the landscape. Historically, traditional state-sponsored cyber espionage groups have been the most prolific attributed users of zero-day vulnerabilities. Over the last few years, the increase of zero-day exploitation attributed to CSVs and their customers has demonstrated the growing ability of these vendors to provide zero-day access to a wider range of threat actors than ever before. 

GTIG has reported extensively on the capabilities CSVs provide their clients as well as how many CSV customers use zero-day exploits in attacks which erode civil liberties and human rights. In late 2025, we reported on how Intellexa, a prolific procurer and user of zero-days, adapted its operations and tool suite and continues to deliver extremely capable spyware to high paying customers. 

People’s Republic of China (PRC)-Nexus Cyber Espionage Groups Still Most Prolific 

Although the proportion of 2025 zero-day exploitation that we attributed to traditional state-sponsored cyber espionage groups was lower than in previous years, these groups remained significant developers and users of zero-day exploits in 2025. Consistent with the trend we have observed for nearly a decade, PRC-nexus cyber espionage groups remained the most prolific users of zero-days across state actors in 2025. We attributed the use of at least 10 zero-days to assessed PRC-nexus cyber espionage groups. This was double what we attributed to these groups in 2024, but below the 12 zero-days we attributed in 2023. PRC-nexus espionage zero-day exploitation continued to focus on edge and networking devices that are difficult to monitor, allowing them to maintain long-term footholds in strategic networks. Examples of this include the exploitation of CVE-2025-21590 by UNC3886 and the exploitation of CVE-2025-0282 by UNC5221.

Observed mass exploitation of vulnerabilities suggests that PRC-nexus espionage operators are increasingly adept at developing, sharing, and distributing exploits among themselves. Historically, zero-day exploits were closely held and leveraged only by the most resourced threat groups. Over time, however, we have observed that an increasing number of activity clusters are exploiting vulnerabilities closer to public disclosure, indicating that PRC-nexus espionage operators have potentially reduced the time to both develop exploits and distribute them among otherwise separate groups. This is reflected not only in the gradual proliferation of exploit code targeting specific vulnerabilities, but also by the shrinking gap between the public disclosure of n-day vulnerabilities and their widespread exploitation by multiple groups. 

In sharp contrast to 2024, during which we attributed the exploitation of five zero-days to North Korean state-sponsored threat actors, we did not attribute any zero-days to North Korean groups in 2025.

Financially Motivated Exploitation Spikes

We tracked the exploitation in 2025 of nine zero-days by likely or confirmed financially motivated threat groups, including the reported exploitation of two zero-days in operations that led to ransomware deployment. This almost ties the previous high of 10 zero-days we attributed to financially motivated groups in 2023 and is nearly double the five zero-days we attributed to financially motivated actors in 2024. Although the total volume of zero-day exploitation we have attributed to financially motivated groups has varied year over year, the sustained presence of these threat actors in the zero-day landscape reflects their continued investment in zero-day exploit development and deployment. Financially motivated actors, including ransomware affiliates, were linked to a substantial number of enterprise exploits, reflecting a trend we observed across multiple motivations.

• We observed zero-day exploitation by FIN11 or associated clusters in four of the last five years–2021, 2023, 2024, and 2025. In late September 2025, GTIG began tracking a new, large-scale extortion campaign by a threat actor claiming affiliation with the CL0P extortion brand, which has predominantly been used by FIN11. The actor sent a high volume of emails to executives at numerous organizations, alleging the theft of sensitive data from the victims' Oracle E-Business Suite (EBS) environments. Our analysis indicated that the CL0P extortion campaign followed months of intrusion activity targeting EBS customer environments. The threat actor exploited CVE-2025-61882 and/or CVE-2025-61884 as a zero-day against Oracle EBS customers as early as Aug. 9, 2025, weeks before a patch was available, with additional suspicious activity dating back to July 10, 2025.
• GTIG identified UNC2165, a financially motivated group that overlaps with public reporting on Evil Corp and has prominent members in Russia, leveraging CVE-2025-8088 to distribute malware in mid-July 2025. This activity marked the first instance where we observed UNC2165 use a zero-day for initial access. Additional evidence from underground activity and VirusTotal RAR archive submissions indicate that CVE-2025-8088 was also exploited during this same period by other actors, including a threat cluster with suspected overlaps with CIGAR/UNC4895 (publicly reported as RomCom). UNC4895 is another Russian threat group that has conducted both financially motivated and espionage operations, including the exploitation of two other zero-days in 2024.

Spotlights: Notable Threat Actor Activity and Techniques

Browser Sandbox Escapes

The discovery of various browser sandbox escapes in 2025 provided an opportunity to evaluate current trends and developments in this area. Analysis of those identified this year revealed a significant trend: none were generic to the browser sandbox itself (e.g., CVE-2021-37973, CVE-2023-6345, CVE-2023-2136); instead, these sandbox escapes were specifically designed to exploit components of either the underlying operating system or hardware used. This section gives a brief technical overview of these vulnerabilities.

Operating System-Based Sandbox Escapes

CVE-2025-2783 targeted the Chrome sandbox on Windows. The vulnerability was caused by the improper handling of sentinel OS handles (-2) that weren’t properly validated. By manipulating inter-process communication (IPC) messages via the ipcz framework, an attacker could relay these special handles back to a renderer process. The exploit allowed a compromised renderer to gain access to handles, leading to code injection within more privileged processes and ultimately to a sandbox escape.

CVE-2025-48543 affected the Android Runtime (ART), the system that translates application bytecode into native machine instructions to improve execution speed and power efficiency. A UAF vulnerability occurred during the deserialization of Java objects, such as abstract classes, that should not be instantiable in the first place. The most notable aspect of the exploit is how the bug can be reached from a compromised Chrome renderer. On recent Android versions, the exploit sent a Binder transaction to deliver a serialized payload embedded into a Notification Parcel object. The subsequent unparceling of the malicious object caused a UAF in ART, leading to arbitrary code execution within system_server, a service that operates with system-level privileges. While this specific vulnerability class and attack vector may be new publicly, we have observed Parcel mismatch n-day vulnerabilities being exploited to achieve Chrome sandbox escapes using the same attack vector in the past.

Device-Specific Sandbox Escapes

CVE-2025-27038 is a UAF vulnerability in the Qualcomm Adreno GPU user-land library that can be triggered through a sequence of WebGL commands followed by a specifically crafted glFenceSync call. The vulnerability allows attackers to achieve code execution within the Chrome GPU process on Android devices. We observed in-the-wild exploitation of this vulnerability in a chain with vulnerabilities in the Chrome renderer (CVE-2024-0519) and the KGSL driver (CVE-2023-33106).

In a similar instance, CVE-2025-6558 targeted the Mali GPU user-land library. This vulnerability was triggered by a sequence of OpenGLES calls that were not properly validated by the browser. Specifically, an out-of-bounds write was caused within the user-land driver due to the issuance of glBufferData() with the GL_TRANSFORM_FEEDBACK_BUFFER parameter while a previous glBeginTransformFeedback() operation remained active. Google addressed this issue in ANGLE by implementing validation to invalidate this specific call sequence. We observed in-the-wild exploitation of this vulnerability in a chain with vulnerabilities in the Chrome renderer (CVE-2025-5419) and in the Linux kernel's posix CPU timers implementation (CVE-2025-38352).

Additionally, CVE-2025-14174 is a vulnerability that affected the Metal backend on Apple devices. In that case, ANGLE incorrectly communicated a buffer size during the implementation of texImage2D operation, resulting in an out-of-bounds memory access within the Metal GPU user-mode driver.

SonicWall Full-Chain Exploit

In late 2025, GTIG collected a multi-stage exploit for SonicWall Secure Mobile Access (SMA) 1000 series appliances. The exploit chain leveraged multiple vulnerabilities to provide either authenticated or unauthenticated remote code execution as root on a targeted appliance, including one that was being leveraged as zero-day.

Authentication Bypass (n-day)

The exploit can be leveraged with or without an authenticated JSESSIONID session token. When executed without a token, the exploit attempts to get one for the built-in admin user by exploiting a weakness in SSO token generation within the Central Management Server feature in SMA 1000.

This vulnerability was patched as a part of CVE-2025-23006. It was reported to SonicWall by Microsoft Threat Intelligence Center (MSTIC), and was reportedly exploited in the wild prior to it being patched in January 2025. GTIG is currently unable to assess if prior exploitation of this vulnerability is linked to use of this new exploit chain.

Remote Code Execution (n-day)

Once the exploit has a valid session cookie for the target, it attempts to attain remote code execution through a deserialization vulnerability, where an object is serialized and encoded with Base64, and then passed between the web application client and the appliance server without any integrity checks. This allows an attacker to forge a malicious Java object and send it to the server, which parses the object and causes arbitrary Java bytecode to be executed. The exploit leverages this primitive to run arbitrary shell commands using a payload generated by ysoserial, a common tool used to assist with exploiting Java serialization-related vulnerabilities.

This vulnerability was patched by encrypting objects with AES-256-ECB prior to sending them to the client, using an ephemeral key generated randomly at server startup and stored in-memory. Payloads mutated without knowledge of the key won't be successfully parsed, which mitigates the risk of deserializing untrusted objects without another vulnerability leaking the encryption key. The patch was silently released in March 2024 without a CVE.

Local Privilege Escalation (0-day)

After exploiting the aforementioned deserialization vulnerability, the exploit is able to execute arbitrary shell commands as the mgmt-server user, which runs the Java process hosting the management web application. To escalate to root privileges, the exploit used a zero-day in ctrl-service, a custom XML-RPC service written in Python and bound to a loopback address on port 8081. This makes it inaccessible directly to a remote attacker, but accessible after already gaining code execution on the device at a lower privilege level. While this vulnerability could be exploited when combined with a newly discovered RCE vulnerability, or with direct console/SSH access to the appliance, we've presently only observed it being chained with the RCE exploit previously discussed.

GTIG reported this vulnerability to SonicWall, who published a patch for it in December 2025 as CVE-2025-40602. To fix this vulnerability, SonicWall added signature verification to the service to prevent it from executing unsigned files.

DNG Vulnerabilities

This section specifically examines samples exploiting CVE-2025-21042, a vulnerability for which GTIG has not confirmed zero-day exploitation; however, we include this discussion of the underlying exploitation techniques because zero-days CVE-2025-21043 and CVE-2025-43300 share identical exploitation conditions.

Between July 2024 and February 2025, several suspicious image files were uploaded to VirusTotal. Thanks to a lead from Meta, these samples came to the attention of Google Threat Intelligence Group. Upon investigation of these images, we discovered that they were digital negative (DNG) images targeting the Quram library, an image parsing library specific to Samsung devices.  

The VirusTotal submission filenames of several of these exploits indicated that these images were received over WhatsApp. The final payload, however, indicated that the exploit expects to run within the com.samsung.ipservice process. This is a Samsung-specific system service responsible for providing “intelligent” or AI-powered features to other Samsung applications, and will periodically scan and parse images and videos in Android’s MediaStore.

When WhatsApp receives and downloads an image, it will insert the image in MediaStore. This permits downloaded WhatsApp images (and videos) to hit the image parsing attack surface within the com.samsung.ipservice application. However, WhatsApp does not intend to automatically download images from untrusted contacts. Without additional bypasses, and assuming the image is sent by an untrusted contact, a target would have to click the image to trigger the download and have it added to the MediaStore. This classifies as a “1-click” exploit. GTIG does not have any knowledge or evidence of the attacker using such a bypass to achieve 0-click exploitation.

com.samsung.ipservice comes with a proprietary image parsing library named “Quram,” which is written in C++. The image parsing is done in-process, unsandboxed with respect to the service’s privilege. This breaks the Rule Of 2 and means a single memory corruption vulnerability can grant attackers access to everything to which com.samsung.ipservice has access, i.e. a phone’s entire MediaStore.

This is exactly what the attackers did when they discovered a powerful memory corruption vulnerability (CVE-2025-21042), which allows controlled out-of-bounds write at controlled offsets from a heap buffer. With this single vulnerability, they were able to obtain code execution within the com.samsung.ipservice process and execute a payload with that process’ privileges.

There were no significant hurdles for the attackers aside from some ASLR bypassing tricks. No control flow integrity mitigations, like pointer authentication code (PAC) or branch target identification (BTI), are compiled into the Quram library. This allowed the attackers to use arbitrary addresses as jump-oriented programming (JOP) gadgets and construct a bogus vtable. The scudo allocator also failed to engage proper hardening techniques. The heap spraying primitives - more or less inherent to the DNG format - are powerful and allow for a predictable heap layout, even with scudo’s randomization strategy. The absence of scudo’s “quarantine” feature on Android is also convenient for deterministically reclaiming a free’d allocation.

This case illustrates how certain image formats can provide strong primitives out of the box for turning a single memory corruption bug into 0-click ASLR bypasses and resulting remote code execution. By corrupting the bounds of the pixel buffer using CVE-2025-21042, subsequent exploitation can occur by taking advantage of the DNG specification and its implementation.

The bug exploited in this case is both powerful and quite shallow. As Project Zero’s Reporting Transparency illustrates, several other vulnerabilities in the same component have been discovered over the recent months.

These types of exploits do not need to be part of long and complex exploit chains to achieve something useful for attackers. By finding ways to reach the right attack surface with a single relevant vulnerability, attackers are able to access all the images and videos of an Android’s MediaStore, posing a powerful capability for surveillance vendors.

A more detailed technical analysis of the exploit can be found on Project Zero’s blog.

Prioritizing Defenses and Mitigating Zero-Day Threats

Defenders should prepare for when, not if, a compromise happens. GTIG continues to observe vulnerability exploitation as the number one initial access vector in Mandiant incident response investigations, outnumbering other vectors like stolen credentials and phishing. System architectures should be designed and built with ingrained security awareness, enabling inherent segmentation and least privilege access. Comprehensive defensive measures as well as response efforts require a real-time inventory of all assets to be audited and maintained. While not preventative, continuous monitoring and anomaly detection, within both systems and networks, paired with refined and actionable alerting capabilities is a real-time way to detect and act against threats as they occur. 

The following is a non-comprehensive set of approaches and guidelines for defending against zero-day exploitation on both personal devices and within organizational infrastructure:

1. Architectural Hardening & Surface Reduction

• • Infrastructure:

    • Ensure your DMZ, firewalls, and VPNs are properly segmented from critical assets, including the core network and domain controllers, in order to prevent lateral movement from compromised external components.

    • Monitor execution flow within applications in order to block unauthorized database queries and shell commands

    • Do not expose network ports of devices to the internet when not strictly required

  • Personal devices:

    • Turn off the device and/or leave the device at home when under increased risk of exploitation.

    • Put the device in before first unlock (BFU) mode and USB restricted mode when under increased risk of physical attacks.

    • Turn off cellular, WiFi and bluetooth when under increased risk of close proximity attacks.

    • Apply patches as soon as they become available.

    • Use ad blockers, configure Apple ad privacy settings, and enable the Android privacy sandbox options when possible.

    • Enable Android Advanced Protection Mode and iOS Lockdown Mode.

    • Remove applications, and disable services and features- including ones enabled by default- when not used.

2. Advanced Detection & Behavioral Monitoring

• • Infrastructure:

    • Enforce strict driver blocklists and flag anomalous kernel-level behavior that traditional EDR might overlook.

    • Establish a baseline for system processes in order to be able to flag "Living off the Land" (LotL) activity and other persistence mechanisms.

    • Deploy canary tokens and files to collect high-fidelity alerts of lateral movement.

  • Personal devices:

    • Seek expert advice (e.g., Amnesty, CitizenLab, and Access Now) when receiving suspicious links or attachments, as well as when observing suspicious application and or operating system crashes.

    • Enroll in Google’s Advanced Protection Program.

    • Enable Android Advanced Protection Mode.

    • Enable Enhanced Safe Browsing in Chrome.

    • Enable Safari fraudulent website warning.

    • Enable Edge enhanced security protections.

3. Operational Response

• • Infrastructure:

    • Maintain a Software Bill of Materials (SBoM) to reference and locate affected libraries of disclosed zero-days (e.g., Log4j) across the environment.

    • Establish a process for bypassing standard change management when vulnerabilities require immediate attention.

    • If a patch is unavailable, isolate systems and components with stop-gap measures such as disabling specific services or blocking specific ports at the perimeter.

  • Personal devices:

    • Reboot phone regularly.

    • Do not click on links or download attachments from unknown contacts.

Prioritization is a consistent struggle for most organizations due to limited resources requiring deciding what solutions are implemented–and for every choice of where to put resources, a different security need is neglected. Know your threats and your attack surface in order to prioritize decisions for best defending your systems and infrastructure.

from Threat Intelligence https://ift.tt/P93cf2m
via IFTTT

Preparing for the Quantum Era: Post-Quantum Cryptography Webinar for Security Leaders

Most organizations assume encrypted data is safe.

But many attackers are already preparing for a future where today’s encryption can be broken. Instead of trying to decrypt information now, they are collecting encrypted data and storing it so it can be decrypted later using quantum computers.

This tactic—known as “harvest now, decrypt later”—means sensitive data transmitted today could become readable years from now once quantum capabilities mature.

Security leaders who want to understand this risk and how to prepare can explore it in detail in the upcoming webinar on Post-Quantum Cryptography best practices, where experts will explain practical ways organizations can begin protecting data before quantum decryption becomes possible.

Why Post-Quantum Cryptography Matters

Quantum computing is advancing quickly, and most modern encryption algorithms, such as RSA and ECC, will not remain secure forever.

For organizations that must keep data confidential for many years—financial records, intellectual property, government communications—waiting is not an option.

A practical approach emerging today is hybrid cryptography, which combines traditional encryption with quantum-resistant algorithms like ML-KEM. This allows organizations to strengthen security without disrupting existing systems.

The Future-Ready Security webinar will explain how hybrid cryptography works in real environments and how organizations can begin transitioning to quantum-safe protections.

Preparing for the Quantum Era

Organizations preparing for quantum threats are focusing on a few key steps:

• Identify sensitive data that must remain protected long-term
• Understand where encryption is used across systems
• Begin adopting hybrid cryptography strategies
• Maintain visibility into cryptographic algorithms and compliance needs

At the same time, security teams must still inspect encrypted traffic and enforce policies across their networks. Modern Zero Trust architectures play an important role in maintaining this control.

These strategies—and how platforms like Zscaler implement them—will be discussed during the live webinar session designed for IT, security, and networking leaders.

What You’ll Learn in the Webinar

This session will cover:

• The growing risk of “harvest now, decrypt later” attacks
• How ML-KEM hybrid encryption helps organizations transition safely
• How post-quantum traffic inspection enables policy enforcement at scale
• Best practices for protecting sensitive data in the quantum era

Quantum computing will reshape cybersecurity. Organizations that begin preparing early will be better positioned to protect their most critical data.

Join the webinar to learn how to build a practical, quantum-ready security strategy before the threat becomes urgent.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/oXniVrU
via IFTTT

MTU Size: What It Is, Why It Matters, and When to Use Jumbo Frames

MTU controls how much data fits into a single network packet. It affects throughput, fragmentation, CPU overhead, and how predictable your network behaves under load. If you’re running storage replication, virtualization, or iSCSI over 10GbE, MTU is one of those settings that’s easy to leave at default and forget about – until something doesn’t perform the way you expect.

Most admins start thinking about MTU after an iperf test on a 10GbE link comes back well below line rate. That’s usually when someone suggests jumbo frames. Sometimes it helps. Often, the real problem is somewhere else.

What is MTU?

MTU (Maximum Transmission Unit) is the largest payload a single Ethernet frame can carry without fragmentation. The standard default is 1500 bytes. When people say “jumbo frames,” they mean an MTU of 9000 bytes – six times the payload per packet.

One thing to keep straight: MTU is not the total frame size. A standard Ethernet frame includes 14 bytes of header (source/destination MAC addresses and EtherType) plus the payload. So an MTU of 1500 means a total frame of 1514 bytes on the wire. MTU only refers to the payload portion.

There’s also a distinction between Layer 2 frame size and Layer 3 IP MTU. Switches enforce frame limits at Layer 2, while hosts and routers work with IP MTU at Layer 3. Both need to agree if jumbo frames are going to work. A mismatch at any hop in the path causes fragmentation or drops.

How MTU works in practice

When your application sends data, it passes through the transport layer (TCP or UDP), gets wrapped in an IP header at Layer 3, and is encapsulated in an Ethernet frame at Layer 2. MTU sets the ceiling on that Layer 2 payload. If the IP packet exceeds the link MTU, something has to give – either the packet gets fragmented, or it gets dropped.

TCP handles this more gracefully than UDP. TCP uses MSS (Maximum Segment Size) during the handshake, so both sides agree on a packet size upfront. If one side is at 9000 and the other at 1500, TCP will negotiate down to 1500. UDP has no such negotiation – the sender just fires packets, and if they’re too large, they either get fragmented or silently dropped, depending on the DF (Don’t Fragment) bit.

There’s also Path MTU Discovery (PMTUD), which is supposed to detect the smallest MTU along the entire path. It works by sending packets with the DF bit set and waiting for ICMP “Fragmentation Needed” messages from routers that can’t forward them. The problem is that many firewalls block ICMP entirely, creating what’s called a PMTUD black hole – the sender never learns the packet is too big, keeps retransmitting, and the connection stalls. This is one of the more frustrating network issues to debug because ping works fine (small packets), but bulk transfers hang.

Standard MTU values and jumbo frames

1500 bytes has been the Ethernet default for decades. It stuck around because it works reliably with virtually all hardware, and it’s a reasonable balance between efficiency and compatibility. PPPoE connections typically use 1492 bytes due to the 8-byte encapsulation overhead.

Jumbo frames (MTU 9000) are common in storage networks, iSCSI deployments, and HPC clusters. The appeal is straightforward: more data per packet means fewer packets to process. At MTU 1500, transferring 20 GB requires roughly 14.3 million packets. At MTU 9000, that drops to about 2.4 million – an 83% reduction in packet count.

One detail that trips people up: enabling jumbo frames on a switch only means the switch will forward larger frames. It doesn’t change the MTU on connected hosts. You have to configure both sides. And in Windows, the network adapter might show 9014 bytes while Linux shows 9000 – the difference is just how headers are counted in the driver UI. They’re functionally the same.

Figure 1: Difference between Standard and Jumbo frames

MTU and performance: the real numbers

The theoretical overhead saving from jumping to MTU 9000 is about 3-4% – you go from roughly 95% payload efficiency to 99%. That’s real, but it’s not dramatic. The bigger win is in packet rate reduction: fewer packets means fewer interrupts, less buffer churn, and less CPU time spent in the network stack.

In practice, the performance gain depends heavily on your hardware and workload. Community benchmarks on various storage forums and our own experience show a consistent pattern: on 10GbE with modern CPUs and NIC offloading (TCP Segmentation Offload, interrupt coalescing), the difference between MTU 1500 and 9000 is often 5-15% for large sequential transfers, and close to zero for mixed or interactive traffic.

For context: at MTU 1500 on 10GbE, you’re pushing around 810,000 packets per second at line rate. Modern CPUs and NIC offload engines handle that without breaking a sweat. Jumbo frames drop that to about 135,000 pps – a reduction that mattered more ten years ago when CPUs were the bottleneck.

Bottom line: jumbo frames are worth it for sustained, large-block transfers on dedicated storage networks – especially if your hardware is older or CPU-constrained. For general-purpose networks, web traffic, email, or remote desktops, MTU 1500 is fine.

Also, don’t assume MTU is always the problem when iperf numbers are low. TCP window size, the number of parallel streams (the -P flag in iperf), CPU saturation, and OS network stack tuning are more common culprits. Test those first.

MTU in virtualization, storage, and cloud

Virtualization adds layers where MTU can go wrong. Packets travel from a physical NIC through a virtual switch, into a VM’s virtual NIC. A mismatch at any layer – hypervisor vSwitch, physical switch, or VM NIC – means fragmentation or drops. In mixed environments where you can’t guarantee end-to-end jumbo support, staying at 1500 is the pragmatic choice.

Storage replication is the strongest use case for jumbo frames. SAN traffic, iSCSI sessions, and block-level replication involve continuous, high-volume, large-block transfers – exactly the workload profile where reduced packet overhead matters. If you’re running a dedicated 10GbE (or faster) replication network where you control every hop, MTU 9000 makes sense. The key word is “dedicated” – don’t mix jumbo frame traffic with general LAN traffic on the same VLAN.

Cloud and hybrid environments complicate things. AWS supports MTU 9001 within a single VPC, but VPN and inter-region connections drop back to 1500 (or lower). Azure defaults to 1500 for most networking. GCP uses 1460 over VPN tunnels. In hybrid setups, set your MTU to match the lowest link in the path. Getting this wrong is one of the most common causes of mysteriously slow VPN-connected replication.

Common MTU misconfigurations

MTU problems are frustrating because they’re subtle. Everything looks fine until you start pushing large packets, and then throughput tanks or connections stall under load.

The classic mistake: servers and switches are set to MTU 9000, but one intermediate device – a firewall, a load balancer, a misconfigured VLAN trunk – supports only 1500. Large packets hit that device and either get fragmented (adding overhead and reassembly cost) or silently dropped. The result is unpredictable throughput and latency spikes, which is the opposite of what you were trying to achieve.

Some specific hardware can also cause problems. Certain Intel X710 NICs have shown increased CPU utilization and throughput instability when jumbo frames are enabled. If you see weird behavior after enabling 9000-byte MTU, the NIC driver is worth investigating before blaming the network.

PMTUD black holes (described above) are another common pain point. If your firewall blocks ICMP, PMTUD can’t do its job, and TCP connections hang during data transfer while small pings succeed. This is notoriously hard to diagnose. The fix is to allow ICMP type 3 (Destination Unreachable) through your firewall, or use MSS clamping as a workaround.

How to check and tune MTU size

Rule number one: MTU must be consistent across the entire path. Every NIC, switch, virtual interface, router, and firewall in the path needs the same value. Increasing MTU on the endpoints without checking every hop in between is how you create fragmentation problems.

Before touching MTU at all, verify that your throughput issue is actually MTU-related. Check CPU utilization, NIC offload settings, TCP window size, and your test methodology. MTU should not be the first thing you change.

Check current MTU

Windows: netsh interface ipv4 show subinterfaces

Linux: ip link show

Test maximum MTU along a path

Windows: ping -f -l 8000 <destination IP>

Linux: ping -M do -s 8000 <destination IP>

The -f (Windows) and -M do (Linux) flags set the Don’t Fragment bit. If the packet is too large for the path, you’ll get an error. Decrease the size until it passes to find your path MTU.

Tip: when setting switch MTU for jumbo frames, set it slightly higher than 9000 (e.g. 9198 or 9216). This gives headroom for any additional encapsulation headers (VLAN tags, VXLAN, etc.) and prevents edge-case fragmentation.

MTU in StarWind storage environments

StarWind Virtual SAN (VSAN) replicates data at the block level between nodes. This is sustained, high-volume traffic – exactly the workload where jumbo frames pay off. On a dedicated 10GbE replication network, setting MTU to 9000 reduces packet rate and lowers CPU overhead during synchronization.

The non-negotiable requirement is end-to-end consistency. Jumbo frames must be enabled on every component in the replication path: NICs, hypervisor virtual switches, physical switches, and VLAN interfaces. If one link in the chain doesn’t support 9000, you’re worse off than staying at 1500. In StarWind deployments, MTU configuration is part of the storage network design from the start – not an afterthought.

Conclusion

For general traffic, leave MTU at 1500. It’s reliable, universally compatible, and modern hardware handles the packet rate without issue. Jumbo frames belong on dedicated, controlled storage or replication networks where every hop is configured consistently and the workload is large sequential transfers.

If you do change MTU, verify every device in the path before and after. One mismatched hop is enough to create fragmentation that negates whatever performance you hoped to gain.

from StarWind Blog https://ift.tt/L5UimDz
via IFTTT

Dust Specter Targets Iraqi Officials with New SPLITDROP and GHOSTFORM Malware

A suspected Iran-nexus threat actor has been attributed to a campaign targeting government officials in Iraq by impersonating the country's Ministry of Foreign Affairs to deliver a set of never-before-seen malware.

Zscaler ThreatLabz, which observed the activity in January 2026, is tracking the cluster under the name Dust Specter. The attacks, which manifest in the form of two different infection chains, culminate in the deployment of malware dubbed SPLITDROP, TWINTASK, TWINTALK, and GHOSTFORM.

"Dust Specter used randomly generated URI paths for command-and-control (C2) communication with checksum values appended to the URI paths to ensure that these requests originated from an actual infected system," security researcher Sudeep Singh said. "The C2 server also utilized geofencing techniques and User-Agent verification."

A notable aspect of the campaign is the compromise of the Iraqi government-related infrastructure to stage malicious payloads, not to mention the use of evasion techniques to delay execution and fly under the radar.

The first attack sequence begins with a password-protected RAR archive, within which there exists a .NET dropper named SPLITDROP, which acts as a conduit for TWINTASK, a worker module, and TWINTALK, a C2 orchestrator.

TWINTASK, for its part, is a malicious DLL ("libvlc.dll") that's sideloaded by the legitimate "vlc.exe" binary to periodically poll a file ("C:\ProgramData\PolGuid\in.txt") every 15 seconds for new commands and run them using PowerShell. This also includes commands to establish persistence on the host via Windows Registry changes. The script output and errors are captured in a separate text file ("C:\ProgramData\PolGuid\out.txt").

TWINTASK, upon first launch, is designed to execute another legitimate binary present in the extracted archive ("WingetUI.exe"), causing it to sideload the TWINTALK DLL ("hostfxr.dll"). Its primary goal is to reach out to the C2 server for new commands, coordinate tasks with TWINTASK, and exfiltrate the results back to the server. It supports the ability to write the command body from the C2 response to "in.txt," as well as download and upload files.

"The C2 orchestrator works in parallel with the previously described worker module to implement a file-based polling mechanism used for code execution," Singh said. "Upon execution, TWINTALK enters a beaconing loop and delays execution by a random interval before polling the C2 server for new commands."

The second attack chain represents an evolution of the first, consolidating all the functionality of TWINTASK and TWINTALK into a single binary dubbed GHOSTFORM. It makes use of in-memory PowerShell script execution to run commands retrieved from the C2 server, thereby eliminating the need for writing artifacts to disk.

That's not the only differentiating factor between the two attack chains. Some GHOSTFORM binaries have been found to embed a hard-coded Google Forms URL that's automatically launched on the system's default web browser once the malware begins execution. The form features content written in Arabic and masquerades as an official survey from Iraq's Ministry of Foreign Affairs.

Zscaler's analysis of the TWINTALK and GHOSTFORM source code has also uncovered the presence of placeholder values, emojis, and Unicode text, suggesting that generative artificial intelligence (AI) tools may have been used to assist with the malware's development.

What's more, the C2 domain associated with TWINTALK, "meetingapp[.]site," is said to have been used by the Dust Specter actors in a July 2025 campaign to host a fake Cisco Webex meeting invitation page that instructs users to copy, paste, and run a PowerShell script to join the meeting. The instructions mirror a tactic widely seen in ClickFix-style social engineering attacks.

The PowerShell script, for its part, creates a directory on the host, and attempts to fetch an unspecified payload from the same domain and save it as an executable within the newly created directory. It also creates a scheduled task to run the malicious binary every two hours.

Dust Specter's connections to Iran are based on the fact that Iranian hacking groups have a history of developing custom lightweight .NET backdoors to achieve their goals. The use of compromised Iraqi government infrastructure has been observed in past campaigns linked to threat actors like OilRig (aka APT34).

"This campaign, attributed with medium-to-high confidence to Dust Specter, likely targeted government officials using convincing social engineering lures impersonating Iraq's Ministry of Foreign Affairs," Zscaler said. "The activity also reflects broader trends, including ClickFix-style techniques and the growing use of generative AI for malware development."

from The Hacker News https://ift.tt/NDop9aP
via IFTTT

UAT-9244 targets South American telecommunication providers with three new malware implants

• Cisco Talos is disclosing UAT-9244, who we assess with high confidence is a China-nexus advanced persistent threat (APT) actor closely associated with Famous Sparrow.
• Since 2024, UAT-9244 has targeted critical telecommunications infrastructure, including Windows and Linux-based endpoints and edge devices in South America, proliferating access via three malware implants.
• The first backdoor, “TernDoor,” is a new variation of the previously disclosed, Windows-based, CrowDoor malware.
• Talos also discovered that UAT-9244 uses “PeerTime,” an ELF-based backdoor that uses the BitTorrent protocol to conduct malicious operations on an infected system.
• UAT-9244’s third implant is a brute force scanner, which Talos tracks as “BruteEntry.” BruteEntry is typically installed on network edge devices, essentially converting them into mass-scanning proxy nodes, also known as Operational Relay Boxes (ORBs) that attempt to brute force into SSH, Postgres, and Tomcat servers.

---

Introducing TernDoor: A variant of CrowDoor

UAT-9244 used dynamic-link library (DLL) side-loading to activate multiple stages of their infection chain. The actor executed “wsprint[.]exe”, a benign executable that loaded the malicious DLL-based loader “BugSplatRc64[.]dll”. The DLL reads a data file named “WSPrint[.]dll” from disk, decrypts its contents, and executes them in memory to activate TernDoor, the final payload.

TernDoor is a variant of CrowDoor, a backdoor deployed in recent intrusions linked to China-nexus APTs such as FamousSparrow and Earth Estries. CrowDoor is a variant of SparrowDoor, another backdoor attributed to FamousSparrow. CrowDoor has also been observed in previous Tropic Trooper intrusions,  indicating a close operational relationship with FamousSparrow. Based on the overlap in tooling; tactics, techniques, and procedures (TTPs); and victimology, we assess with high confidence that UAT-9244 closely overlaps with FamousSparrow and Tropic Trooper.

Although UAT-9244 and Salt Typhoon both target telecommunications service providers, Talos has not been able to verify or establish a solid connection between the two clusters.

The DLL-based loader

The DLL-based loader, “BugSplatRc64.dll”, will load the “WSPrint.dll” file from the current directory, which will be decoded using the key “qwiozpVngruhg123”.

Figure 1. DLL-based loader reading the encoded payload.

The decoded shellcode is position-independent and decodes and decompresses the final payload. The final payload is the TernDoor implant.

TernDoor

The final shellcode consists of the TernDoor backdoor. TernDoor is a variant of CrowDoor, actively developed and used by UAT-9244 since at least November 2024. TernDoor deviates from CrowDoor in the following aspects:

• TernDoor consists of command codes that are different from previously disclosed variants of CrowDoor.
• The TernDoor shellcode also consists of an embedded Windows driver (SYS file). The driver is encrypted using AES in the shellcode. The driver is used to suspend, resume, and terminate processes.

Persistence

The TernDoor infection chain is persisted on the system using either a scheduled task or the Registry Run key.

The scheduled task is named “WSPrint” and created using the command:

schtasks /create /tn WSPrint /tr "C:\ProgramData\WSPrint\WSPrint.exe" /ru "SYSTEM" /sc onstart /F

Furthermore, TernDoor modifies the following task-related registry keys to hide the task:

• Deletes HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\WSPrint | SD
• Modifies HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\WSPrint | Index = from 1 to 0

A Registry Run key may also be set to run the executable on user login:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run | Default = C:\ProgramData\WSPrint\WSPrint.exe

Command line switch

Unlike CrowDoor, TernDoor only supports one command line switch: “-u”, passed to WSPrint.exe. This is the switch for uninstalling the malware from the system and it deletes all malware files from the operating directory, as well as terminates malicious processes.

Decoding the configuration

Like previous variants of CrowDoor, TernDoor also checks to ensure it has been injected into “msiexec[.]exe”. The implant decodes its configuration that can specify the following information:

• Command and control (C2) IP address
• Number of tries to connect to the C2
• C2 port number
• User-Agent to use while connecting to C2 (if applicable)

Figure 2. TernDoor configuration blob.

TernDoor functionality

TernDoor’s capabilities resemble those of previously disclosed CrowDoor samples:

• Communicates with the C2 IP address
• Creates processes and runs arbitrary commands via remote shell and independently
• Reads and writes files
• Collects system information such as computer and user name, IP address information, and OS bitness
• Uninstalls itself from the infected system
• Deploys the accompanying driver to hide malicious components and perform process management

The accompanying Windows driver, WSPrint.sys, is dropped to disk and then activated using a windows service:

Figure 3. Malicious driver service on the infected endpoint.

 The driver creates a device named “\\Device\\VMTool” and symbolically links it to “\\DosDevices\\VMTool”. It can terminate, suspend, or resume processes specified by TernDoor — likely a means of evasion.

TernDoor infrastructure

All the C2 IP addresses discovered by Talos were associated with the following SSL certificate on port 443:

SSL_fingerprint_sha256= 0c7e36683a100a96f695a952cf07052af9a47f5898e1078311fd58c5fdbdecc8
SSL_fingerprint_SHA1= 2b170a6d90fceba72aba3c7bc5c40b9725f43788
Data:
Version: V3
Serial Number: 1
Thumbprint: 2b170a6d90fceba72aba3c7bc5c40b9725f43788
 
Signature Algorithm:
Issuer: C=US ST=Some-State O=Internet Widgits Pty Ltd CN=8.8.8.8
Validity
Not Before: 2022-09-04 12:54:51
Not After: 2023-09-04 12:54:51
Subject: C=US ST=Some-State O=Internet Widgits Pty Ltd CN=8.8.8.8

Pivoting off this certificate, Talos found an additional 18 IPs likely being used by UAT-9244. This list is provided in the indicators of compromise (IOCs) section.

One of the DLL-based loaders was also hosted on the IP “212.11.64[.]105”. On this server, we discovered a set of shell scripts and an accompanying malware family we track as “PeerTime.”

PeerTime: UAT-9244's peer-to-peer (P2P) backdoor

PeerTime is an ELF based backdoor that is compiled for a variety of architectures such as ARM, AARCH, PPC, MIPS etc., indicating that UAT-9244 can use it to infect a variety of embedded systems.

PeerTime is deployed through a shellscript that downloads the PeerTime loader ELF binary and an instrumentor binary.

The instrumentor ELF binary will check for the presence of docker on the compromised host using the commands docker and docker –q.

If docker is found, then the PeerTime loader is executed using:

docker <path_of_PeerTime_loader_ELF>

The instrumentor consists of debug strings in Simplified Chinese, indicating that it is a custom binary created and deployed by Chinese-speaking threat actors:

获取当前程序路径错误:     //Error retrieving current program path:
删除当前程序错误:                // Error deleting current program:

Figure 4. PeerTime installation/infection chain.

PeerTime consists of a loader that will decrypt and decompress the final PeerTime ELF payload and run it in memory. The PeerTime loader has the ability to rename its process to a benign process to evade detection.

PeerTime uses the BitTorrent protocol to obtain C2 information, download files from its peers, and execute them on the infected host. The payloads are written to disk and copied to the specified locations using BusyBox. As of now, PeerTime consists of two versions: one written in C/C++ and a newer version written in Rust.

Figure 5. PeerTime uses busybox to copy payloads.

PeerTime is also known as “angrypeer” and can be tracked in VirusTotal using the “malware_config:angrypeer” query. Malware configurations in VirusTotal are identified using Mandiant’s/GTIG’s Backscatter tool.

Setting up ORBs via BruteEntry

Infrastructure used by UAT-9244 also hosts another set of shell scripts and payloads designed to establish compromised Linux based systems including edge devices as operational relay boxes (ORBs) that scan and brute force Tomcat, Postgres, and SSH servers.

The shell script will download two components:

• An instrumentor and daemon process that activates the actual brute forcer
• The actual brute forcer (named BruteEntry) that obtains target IPs from the C2 server and scans the IPs

Figure 6. BruteEntry infection chain.

The instrumentor binary

The instrumentor binary is an ELF file written in GoLang. It checks if the BruteEntry is already running on the system using “pgrep”:

pgrep <path_to_BruteEntry>

And then starts the brute forcer agent:

./<path_to_BruteEntry>

BruteEntry

BruteEntry is also written in GoLang and begins by registering with the C2 server by providing it with the infected system’s IP address and computer name:

{“ip”:“value”, “hostname”:“value”}

 The C2 responds with a JSON that assigns an agent_id to the infected host:

{“agent_id”:“value”, “server”:“value”}

where “server” = version string of BruteEntry such as “brute-force-server-v1.0”

 BruteEntry will then ask the C2 for tasks to perform by sending a GET request to the C2 at the URI, where limit=1000 is the maximum number of vulnerable IPs to scan:

/tasks/<agent_id>?limit=1000

The C2 responds with a JSON that consists of “tasks” containing the list of IPs to brute force:

{"tasks":[
{"id":,"target":":","type":""},
{"id":,"target":":","type":""},
. . . . .
] }

 The “type” field in the json defines the type of scan to conduct — either “tomcat”,“postgres”, or “ssh”.

The agent will then use a set of embedded credentials to attempt to brute force into either a Tomcat server application at the URL “https[://]<IP>:<Port>/manager/html”, or will brute force into a Postgres instance, either defined in the JSON (<IP><Port>) from the C2 or using the port 5432 if no port is specified.

Figure 7. BruteEntry selecting the type of service to brute force into.

Any successful logins are then POSTED back to the C2:

{"batch":[
{"task_id":<task_id>,"success":<true/false>,"note":" <notes on the task>"},
{"task_id":<task_id>,"success":<true/false>,"note":" <notes on the task>"},
......
]}

 In this instance, “success” indicates if the brute force was successful (true or false), and “notes” provides specific information on whether the brute force was successful. If the login failed, the note reads “All credentials tried.” If it succeeded, the note reads “Cracked by agent <agent_id> | Version <agent_version>”.

Coverage

The following ClamAV signatures detect and block this threat:

• Win.Loader.PeerTime
• Win.Malware.TernDoor
• Unix.Malware.BruteEntry
• Txt.Malware.PeerTime
• Unix.Malware.PeerTime

The following SNORT® rules (SIDs) detect and block this threat: 65551

IOCs

TernDoor Loader DLL

711d9427ee43bc2186b9124f31cba2db5f54ec9a0d56dc2948e1a4377bada289
3c098a687947938e36ab34b9f09a11ebd82d50089cbfe6e237d810faa729f8ff
f36913607356a32ea106103387105c635fa923f8ed98ad0194b66ec79e379a02

 Encoded TernDoor payload

A5e413456ce9fc60bb44d442b72546e9e4118a61894fbe4b5c56e4dfad6055e3
075b20a21ea6a0d2201a12a049f332ecc61348fc0ad3cfee038c6ad6aa44e744
1f5635a512a923e98a90cdc1b2fb988a2da78706e07e419dae9e1a54dd4d682b

Windows driver

2d2ca7d21310b14f5f5641bbf4a9ff4c3e566b1fbbd370034c6844cedc8f0538

UAT-9244 C2 IPs used by TernDoor

154[.]205[.]154[.]82:443
207[.]148[.]121[.]95:443
207[.]148[.]120[.]52:443
212[.]11[.]64[.]105

Suspected UAT-9244 IPs

149[.]28[.]25[.]33
154[.]205[.]154[.]194
154[.]205[.]154[.]65
154[.]205[.]154[.]70
154[.]223[.]21[.]130
154[.]223[.]21[.]194
158[.]247[.]238[.]240
216[.]238[.]112[.]222
216[.]238[.]123[.]242
216[.]238[.]94[.]37
38[.]54[.]125[.]134
38[.]60[.]199[.]34
45[.]32[.]106[.]94
45[.]77[.]34[.]194
45[.]77[.]41[.]141
47[.]76[.]100[.]159
64[.]190[.]113[.]170
64[.]95[.]10[.]253

PeerTime installation script

ebcb2691b7c92cdf2b2ff5e2d753abeea8cb325c16596cd839e6bd147f80e38a
00735a8a50d2856c11150ef1e29c05acebce7ad3edad00e37c7f043aacb46330
74fbc8360d4c95d64d7acaa4d18943dce2d41f91d080b0b5e435d8bce52861a5
babc81fc9c998e9dc4ab545f0e112e34d2641e1333bc81aaa131abd061a5b604
e34c9159e6e78c59518a14c5b96bddfee094b684f99d4f69b13371284a014e87
2c3f2261b00ea45e25eb4e9de2b7ff8e41f311c0b3d986461f834022c08b3b99
3fcced9332301ff70b20c98c9434c858400013d659afa6bb5149cffb0206357d
a313f76fca50fff1bcd6f2c6cbc1268985f8c0a3a05fe7f43c4fc0ac3aff84dc
03eac9eb7f4b4bc494ef0496ee23cabbf38f883896838ed813741d8f64ac9fde
17652d7bb5fe0454023db4fc7f608df0dbe6af237be31258e16ba52f0e895e26
74d1a678bdc4bb9f33321e94e3bd1bc1740472ed734231fc46af720072ecb77e

PeerTime instrumentor binary

c9fc2af30f769d856b88b3051f19fdb663b3e0a0916279df9bbcba93c6a110c9

PeerTime malware

34d64b3cd9430e85edefcb883973a086dd5de9917e05fabec89b1f4ab9627e91
1cedf01dd4b7e50181d0e781825c66957b862941395d77c8bd7705114f319c80
bfc35f12d00fa4b40c5fbce9e37d704e12a52262709bcbdf09f97890bc40cad5
f3e899789b56429f483e5096e1f473335024f1f763e2d428132338e30352b89e
6ec070457d1f6f239cb02c5e1576a3660cca98f3a07eec6e4e107f698d7fe555
15d937803f90c2b9e277ff94d3e98ff30015ecc7f4623a158e3c98861e5cb278
7b70cd956f082b1029d02b4cb7608893f2de7fa9c500d7d7febdd0f745ac3cb6
d78b3c6df8f3756a7e310cf7435fdba201dd03ec9f97420a0db683489a01a7c9
3fcadde4b414a18b2fed56c1ec59d97977123615fbbf411a1c78425445a6e71c
3d9fbfc2c056eac857ba54e5ed134aa45a4b8322ee9f9353ba32e5b2ca71b0e3
c9a42423ef08bd7f183915780d39530eba5e4e25968c51965ff8bb3026965a28
38eeaa4eaad72feb3f8e6993565fcc548d8e7bb93642590f00fa24aacc0e2862
56bead2933e91366e4a0d5761daf5b238a7f2c22e597664ef67b3ecae20ab326
6a2d23cc8746a83e9a3b974788fce0e414706b8e75ff390426dd7e10b19967b3
9a7225c17e4bad3ffe7f080530d36f4f8aca5c116b913caa91ab9b0cee85638e
870e791af14caaf395c56028176a9c3f4c1ff0318ef3112d57ecd3d4a1be2ef9

PeerTime remote locations

185[.]196[.]10[.]247
xtibh[.]com
xcit76[.]com

PeerTime C2s

bloopencil[.]net
185[.]196[.]10[.]38

BruteEntry installation script

1fcdd5a417db31e5e07d32cecfa69e53f0dce95b7130ad9c03b92249f001801d

BruteEntry instrumentor binary

66ce42258062e902bd7f9e90ad5453a901cfc424f0ea497c4d14f063f3acd329
d5eb979cb8a72706bfa591fa57d4ebf7d13cecdc9377b0192375e2f570f796df

BruteEntry agent

66adeedfb739774fcc09aa7426c8fad29f8047ab4caee8040d07c0e84d011611
66bdce93de3b02cf9cdadad18ca1504ac83e379a752d51f60deae6dcbafe4e31

BruteEntry infrastructure

212[.]11[.]64[.]105
185[.]196[.]10[.]247

Additional malicious scripts

023467e236a95d5f0e62e26445d430d749c59312f66cf136e6e2c2d526c46ba1
f8066833e47814793d8c58743622b051070dac09cb010c323970c81b59260f84
06b23d84fd7afd525dfd7860ebd561dcdd72ccbeb51981d5d9a75acf068d0a2a

from Cisco Talos Blog https://ift.tt/uz3jnRC
via IFTTT

Where Multi-Factor Authentication Stops and Credential Abuse Starts

Organizations typically roll out multi-factor authentication (MFA) and assume stolen passwords are no longer enough to access systems. In Windows environments, that assumption is often wrong. Attackers still compromise networks every day using valid credentials. The issue is not MFA itself, but coverage. 

Enforced through an identity provider (IdP) such as Microsoft Entra ID, Okta, or Google Workspace, MFA works well for cloud apps and federated sign-ins. But many Windows logons rely solely on Active Directory (AD) authentication paths that never trigger MFA prompts. To reduce credential-based compromise, security teams need to understand where Windows authentication happens outside their identity stack.

Seven Windows authentication paths that attackers rely on

1. Interactive Windows logon (local or domain joined)

When a user signs in directly to a Windows workstation or server, authentication is typically handled by AD (via Kerberos or NTLM), not by a cloud IdP. 

In hybrid environments, even if Entra ID enforces MFA for cloud apps, traditional Windows logons to domain-joined systems are validated by on-prem domain controllers. Unless Windows Hello for Business, smart cards, or another integrated MFA mechanism is implemented, there’s no additional factor in that flow.

If an attacker obtains a user’s password (or NTLM hash), they can authenticate to a domain-joined machine without triggering the MFA policies that protect software-as-a-service apps or federated single sign-on. From the domain controller’s perspective, this is a standard authentication request.

Tools like Specops Secure Access are key to limiting the risk of credential abuse in these scenarios. By enforcing MFA for Windows logon, as well as for VPN and Remote Desktop Protocol (RDP) connections, this tool makes it harder for attackers to gain unauthorized access to your network. This even extends to offline logins, which are secured with one-time passcode authentication.

Specops Secure Access

2. Direct RDP access that bypasses conditional access

RDP is one of the most targeted access methods in Windows environments. Even when RDP is not exposed to the internet, attackers often reach it through lateral movement after initial compromise. A direct RDP session to a server doesn’t automatically pass through cloud-based MFA controls, which means the logon may rely solely on the underlying AD credential.

3. NTLM authentication

NTLM is a legacy authentication protocol that, despite being deprecated in favor of the more secure Kerberos protocol, still exists for compatibility reasons. It is also a common attack vector because it supports techniques like pass-the-hash.

In pass-the-hash attacks, the attacker does not need the plaintext password; instead, they use the NTLM hash to authenticate. MFA does not help if the system accepts the hash as proof of identity. 

NTLM can also appear in internal authentication flows that organizations may not actively monitor; only an incident or an audit will surface it to security teams.

4. Kerberos ticket abuse

Kerberos is the primary authentication protocol for AD. Instead of stealing passwords directly, attackers steal Kerberos tickets from memory or generate forged tickets after compromising privileged accounts. This enables techniques such as:

• Pass-the-ticket
• Golden Ticket
• Silver Ticket

These attacks allow long-term access and lateral movement and also reduce the need for repeated logons, which lowers the chance of detection. These attacks can persist even after password resets if the underlying compromise is not fully addressed.

5. Local administrator accounts and credential reuse

Organizations still rely on local administrator accounts for support tasks and system recovery. If local admin passwords are reused across endpoints, attackers can escalate one compromise into broad access.

Local admin accounts usually authenticate directly to the endpoint bypassing MFA controls entirely. Entra ID conditional access policies do not apply. This is one reason why credential dumping remains so effective in Windows environments.

6. Server Message Block (SMB) authentication and lateral movement

SMB is used for file sharing and remote access to Windows resources. It’s also one of the most reliable lateral movement paths once an attacker has valid credentials. Attackers commonly use SMB to access administrative shares such as C$ or to interact with systems remotely using valid credentials. 

If SMB authentication is treated as internal traffic, MFA is rarely enforced at this layer. If the attacker has valid credentials, they can use SMB to move between systems quickly.

7. Service accounts that never trigger MFA

Service accounts exist to run scheduled tasks, applications, integrations, and system services. They often have stable credentials, broad permissions, and long lifetimes.

In many organizations, service account passwords do not expire and are rarely monitored. They are also difficult to protect with MFA because the authentication is automated. Frequently, these accounts are used in legacy applications that cannot support modern authentication controls.

This is one reason why attackers target helpdesk credentials and endpoint admin access early in an intrusion.

How to close Windows authentication gaps

Security teams should treat Windows authentication as its own security surface. There are several practical steps security teams can take that reduce exposure:

1. Enforce stronger password policies in AD

A strong password policy should enforce longer passphrases of 15 or more characters. Passphrases are easier for users to remember and harder for attackers to crack. Strong policies should also prevent password reuse and block weak patterns that attackers can guess.

2. Block compromised passwords continuously

Credential theft is not always the result of brute force attacks. Billions of passwords are already available in breach datasets for attackers to reuse in credential attacks. Blocking compromised passwords at the point of creation reduces the chance that users set credentials that attackers already have.

3. Reduce exposure to legacy authentication protocols

Where possible, organizations should restrict or eliminate NTLM authentication. Security teams should set themselves the goal of understanding where NTLM exists, reducing it where possible, and tightening controls where it cannot be removed.

4. Audit service accounts and reduce privilege creep

Treat service accounts as high-risk identities. Organizations should inventory them, reduce unnecessary privileges, rotate credentials, and remove accounts that are no longer needed. If a service account has domain-level permissions, the organization should assume it will be targeted.

How Specops can help 

Strong password policies and proactive checks against known compromised credentials are two of the most effective ways to reduce the risk of credential-based attacks. Specops Password Policy helps by applying flexible password controls that go beyond what’s available natively in Microsoft. 

Specops Password Policy

Its Breached Password Protection feature continuously checks Active Directory passwords against a database of more than 5.4 billion exposed credentials, alerting you quickly if a user password is found to be at risk. If you’re interested in seeing how Specops can help your organization, speak to an expert or book a demo to see our solutions in action.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/tsYgjV5
via IFTTT