Cybersecurity incidents can unfold in hours, but response plans often fail at the point of execution: ownership is unclear, investigation findings is difficult to access, and critical decisions are delayed. That is why incident response cannot be something your organization figures out in real time.
The Detection and Response Team (DART) – the Microsoft team that delivers Defender Experts Cybersecurity Incident Response – has supported organizations across 54 countries and regions through some of their most challenging security moments; and while we sincerely hope you never need to call us in the middle of a live incident, we do want to help you prepare for that possibility before it becomes real.
That’s exactly what the Cybersecurity Incident Response Readiness Workshop is designed to do.
What is the Cybersecurity Incident Response Readiness Workshop?
The Cybersecurity Incident Response Workshop is a collaborative, scenario driven workshop designed to evaluate your organization’s incident response (IR) plan against realistic, real-world security events, guided by DART researchers.
Rather than reviewing your plan in isolation, we work through simulated incidents together. Participants navigate realistic attack scenarios, present investigation findings, discuss decisions, and receive direct feedback from responders with extensive experience handling complex incidents worldwide.
What makes DART’s approach different?
DART’s approach combines active participation with lessons drawn from frontline incident response. Instead of reviewing a plan as a static document, the Cybersecurity Incident Response Workshop exercises how people, processes, and technology work together under pressure. Participants practice detection, containment, and response decisions while DART security researchers provide feedback grounded in real-world incident experience.
The workshop creates a controlled environment for teams to test how they detect, investigate, contain, and communicate during an incident. DART security researchers examine how people, processes, and technology work together across identity, endpoint, cloud, and communications, including whether the organization’s tools, logs, and telemetry support timely decisions against real threat actor behaviors.
Additionally, the workshop includes threat hunting exercises that let incident response teams investigate realistic scenarios with urgency but without the pressure of a live incident. This hands-on practice strengthens technical judgment and helps teams coordinate their response more effectively.
Why organizations run this workshop
The goal is not to pass or fail. It’s to discover how well your organization can make and execute critical response decisions under pressure, and where preparation today can prevent delay during a real incident.
During the Workshop, organizations are able to:
Compare and contrast their incident response plan with insights drawn from DART’s experience across thousands of real‑world cases.
Exercise response processes using real-world scenarios to identify strengths and improvement opportunities, including processes, threat hunting techniques, and the use of cybersecurity technologies.
Identify potential gaps in both tools and procedures before a threat actor finds them.
In short: it’s a chance to see what holds up under pressure, where coordination or visibility begins to bend, and what your organization should reinforce before a threat actor puts the response plan to the test.
Our approach: How we assess your maturity
The workshop blends structured analysis with hands-on knowledge transfer, creating an experience that is both evaluative and practical.
The assessment examines how your organization’s people, processes, and technology support incident response across identity, endpoint, cloud, and communications. It also evaluates whether available tools and telemetry provide the visibility needed to respond to real threat actor tactics.
Additional knowledge transfer is delivered through interactive exercises led by DART, encouraging cross-team collaboration while sharing proven detection and containment practices drawn from real incidents.
What organizations walk away with
By the end of the workshop, organizations leave with a clearer view of how their incident response capability performs today and where focused improvements can strengthen readiness. You’ll take away:
Clear identification of strengths and opportunities in IR preparation and execution.
Insight into how tools, techniques, and available data perform during an incident.
A summary of findings and prioritized recommendations to help strengthen incident response readiness and guide next steps.
Scope and structure
The engagement begins by aligning on objectives, participants, logistics, and expected outcomes so the scenarios and discussions can be tailored to the organization’s needs
The workshop spans 2 or 3 days, including:
Kick off and introductions to understand who the audience is and what they hope to gain from the workshop; this helps us tailor our delivery approach for each unique organization
Knowledge-transfer sessions
Scenarios and guided discussions assessing current capabilities
Closeout and recommended next steps
Practice before it matters
If your incident response plan lives mostly on paper, or if it’s never been exercised with the people who will use it, the Cybersecurity Incident Response Workshop provides a safe, structured way to change that. When a real incident happens, you don’t want your first conversation about roles, investigation findings, or decision-making to happen in the middle of a crisis.
Don’t wait for a live incident to test your response plan, if you have an established Unified Enterprise agreement with Microsoft, reach out to your Customer Success Account Manager (CSAM) to schedule a Cybersecurity Incident Response Workshop and give your teams the opportunity to practice before it matters most.
Learn more
To learn more about DART capabilities, please visit our website, or contact your Microsoft Customer Success Account Manager or Premier Support contact.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Have you ever read the Talos IR Quarterly Trends report and wondered, “How did that phishing or ransomware campaign actually play out? When was Talos IR contacted, how did they contain it, and how did they remediate the environment?"
You’re in luck. Next Tuesday, August 11, Cisco Talos Incident Responders will be hosting an exclusive, unrecorded 30-minute webinar to review the most high-impact incidents our customers faced in Q2 2026. This isn’t a rehashing of the report itself, but a candid discussion of what happened, how we handled it, and what it means for your organization.
The session is designed for security professionals of all levels, from analysts and incident responders to managers and senior leaders. We'll focus on strategic takeaways and business impact, with just enough technical depth to provide context and spark meaningful conversations.
Registration is required to attend. Don’t miss this chance to hear real-world stories from the frontlines of cyber defense, directly from the team who lived them.
Because of the amount of data that can be obtained and the high impact that successful attacks may have, educational institutions are frequent targets of cybercriminals. Both public and private schools and universities rely on software for managing personally identifiable information (PII) that is often insecure or insufficiently tested against known vulnerabilities. In addition, machines used by multiple people without accountability can be vulnerable to insider threats.
The complexity of academic environments amplifies this risk. Unlike corporate networks, educational institutions have to provide a network that supports students, professors, researchers, administrative staff, third-party contractors, and visitors. Each of these groups has different security requirements and access control levels, making it difficult to enforce consistent security policies. A security breach can have severe consequences since it may expose vast amounts of sensitive information, such as social security numbers (CPF in Brazil), addresses, phone numbers, and even parents’ names. Armed with this information, attackers can attempt phishing attacks and impersonate the victims in SIM swapping attacks, a common practice in Brazil.
In this article, we provide details about attacks on educational institutions in Brazil observed by our Global Emergency Response Team (GERT) since 2025. We share general statistics, common threats, initial access vectors, and the impact of such violations. Additionally, we present some interesting cases encountered by our team and the identified TTPs. Finally, we offer recommendations to help institutions protect themselves against future attacks.
Key findings and statistics
Our dataset encompasses incident response cases from January 2025 to June 2026. As the chart below shows, the majority of attacks targeted institutions in São Paulo state, Brazil’s most populous state and a significant center of economic and financial activity. We also had cases in Rio de Janeiro and Pernambuco.
Geographical distribution of incident response requests at educational institutions (download)
Of the customers who requested incident response, 60% were private institutions and 40% were public institutions.
The most frequent reasons for requesting IR services were related to suspicious endpoint activities, encrypted files, and the presence of suspicious files.
The high-severity incidents were mainly related to ransomware attacks. Interestingly, private institutions were the most targeted by ransomware, while incidents in public institutions were mostly related to suspicious endpoint activity and privilege escalation attempts. The most common ransomware families found in our dataset were DragonForce and LockBit 3, whose builder was leaked back in 2022. By using the leaked LockBit builder with a valid privileged account, attackers can build variants capable of disabling defenses and erasing logs.
The most common initial access vectors included the use of valid accounts, exploitation of public-facing applications, and insiders.
For privilege escalation, the attackers often relied on Potato variants (GodPotato, SweetPotato, and BadPotato).
We also observed attackers using tools like AnyDesk for remote access, PsExec for lateral movement within compromised infrastructures, and AV-killer malware to terminate the system’s defenses. The latter was mainly used in ransomware-related incidents.
These data reveal an interesting pattern in the threat landscape affecting educational institutions in the region. Many incidents were not caused by highly sophisticated techniques but rather by the abuse of common weaknesses such as valid accounts, exposed applications, and inadequate patch management, as well as the use of publicly available tools that are well-known to the adversaries. The prevalence of ransomware in private institutions suggests a stronger financial motivation, likely because attackers assume these organizations are more capable of paying for data recovery than public schools and universities.
Most attacks were discovered promptly and lasted from a few minutes to a couple of hours. However, technical incident response activities averaged 9.6 hours. This indicates that the impact caused by an incident often extends beyond the timeframe of the active attack, requiring extensive triage and analysis by the forensic investigators to fully restore operations.
One interesting fact is that we are still observing the use of Windows 10 in the infrastructures of educational institutions, even after Microsoft’s official end-of-support date of October 2025. In addition, we found that some customer organizations were using Windows Server 2016 without security patches and fixes. Using outdated and unsupported operating systems increases the attack surface of an infrastructure because attackers can exploit publicly available vulnerabilities to access vulnerable systems and expand their presence in the network. In addition, legacy operating systems may be incompatible with modern evidence collection tools, necessitating extra time and alternative procedures for forensic acquisition.
In one case, we identified the use of a custom version of LockBit that was generated using the leaked builder. The ransomware was delivered to the organization’s infrastructure via a valid account that had been leaked. It encrypted the organization’s internal systems, including file servers and databases that stored student profiles and other data. There was no evidence of data exfiltration from the affected machines.
During our analysis of the LockBit sample, we were able to extract its configuration. Interestingly, it was configured without the impersonation and spreading options. This meant the attacker had to perform manual lateral movement to deploy the malware across the network.
Further analysis revealed that the attacker used PsExec for lateral movement. By analyzing the Update Sequence Number (USN) Journal, we were able to identify .KEY files associated with PsExec that showed us the previously compromised machines used by the attacker.
After gaining access to the target machines, the adversaries deployed a batch script to disable the system’s defenses. Our analysis of this artifact showed that they had the administrative credentials to disable the EDR in place. In addition, the script enabled RDP, which gave the attackers remote access to the target. The listing below shows an excerpt of the script:
Finally, by cross-checking the Prefetch files, we were able to identify the precise dates of PsExecSvc.exe and LBB.exe (LockBit) execution. This revealed that the attacker established the initial connection to the analyzed machine around 5:30am UTC and ran LBB.exe for the last time at 10am UTC on the same day, resulting in an activity window of approximately four hours and thirty minutes. We were able to identify the extent of the compromise and the additional machines that required network isolation for further forensic analysis, containment, and remediation.
Case 02 – DragonForce deployed via AnyDesk
In another incident, we identified a compromised user account that the adversaries used to install the AnyDesk software to enable remote access. Although the attacker erased the system logs after encrypting the victim’s files, we were able to identify the ransomware execution event via the Prefetch and Amcache.hve files, which provided us with the SHA-1 hash of the sample.
Once we obtained the SHA-1 of the malicious artifact (named by the attacker as 1.EXE), we were able to confirm that it was a DragonForce variant. Even though the lack of evidence made the analysis more difficult, this case shows that forensic investigators must be prepared to identify information that the attackers missed or left untouched.
Case 03 – Python keylogger used by an insider
The third incident illustrates how a series of bad practices enabled an insider to collect passwords from other users inside the infrastructure. First, the customer contacted us stating that a machine was exhibiting strange behavior: files containing passwords were being created. We started with triage collection on one of the affected machines.
Evidence from the Program Compatibility Assistant (PCA) showed the execution of two suspicious files, Windows Host Widgets.exe and Windows Host Widgets_.exe, both located in the C:\Users\<user>\.vscode\dlo directory, where <user> represents a user account shared by everyone who uses the machine. The same artifacts were identified within the Amcache.hve file, and multiple executions were also confirmed by analyzing the Prefetch files. Another interesting source of evidence, UserAssist, confirmed that the threat actor also executed both EXE files by double-clicking on them.
MFT analysis showed that multiple log files named cacheX.txt were created in the previously mentioned directory, where X was a number that increased with each malware execution. We then analyzed the EXE files to confirm their behavior. Luckily, both proved to be the same Python script, which we could easily decompile.
As shown in the listing below, the script contains methods and strings with Portuguese names. It is capable of hiding the log files from view in Explorer. The developer also set a procedure to identify when the Caps Lock key was pressed, in order to record the correct passwords.
def get_base_path():
...
def encontrar_proximo_nome(base='cache'):
...
def set_file_hidden(filepath):
...
ctypes.windll.kernel32.SetFileAttributesW(str(filepath), FILE_ATTRIBUTE_HIDDEN)
...
with open(log_file, 'a', encoding='utf-8') as f:
f.write(f'\n\n--- Registro iniciado em {datetime.datetime.now()} ---\n')
set_file_hidden(log_file)
...
def is_capslock_on():
return bool(ctypes.windll.user32.GetKeyState(20) & 1)
...
def on_press(key):
...
def on_release(key):
...
def main():
with keyboard.Listener(on_press=on_press, on_release=on_release) as listener:
listener.join()
if __name__ == '__main__':
main()
This simple script did not implement any persistence or automated data exfiltration mechanisms. Therefore, the insider likely had to manually retrieve the generated log files containing the text typed by the victims. By revisiting the previously collected evidence, we identified USB connections around the same time as the script’s executions. This suggests that removable media was probably used to collect the generated keylogging logs from the environment. As a result of the investigation, the customer changed the passwords of all affected accounts. However, without additional evidence or footage, it was not possible to conclusively attribute the activities to a specific individual and take the appropriate disciplinary and legal measures.
Conclusions and recommendations
The incidents highlighted in this article demonstrate that Brazilian educational institutions face a diverse set of threats, ranging from ransomware operations to insider activity. In many cases, the attackers relied on valid credentials, exposed services, remote access tools, poor patch management, and insufficient endpoint hardening rather than advanced malware or new techniques. Based on these findings, educational institutions should prioritize controls that reduce the likelihood of account compromise and the impact of ransomware deployment. They should also improve forensic visibility after an incident.
Institutions should enforce the use of multi-factor authentication (MFA) for all publicly accessible services, especially VPNs, remote access portals, and email accounts. Since valid accounts were one of the most common initial access vectors observed in our dataset, MFA can significantly reduce the likelihood that stolen or reused credentials alone will compromise the entire environment. We also recommend periodically reviewing privileged accounts, removing unnecessary administrative permissions, and avoiding shared accounts, especially on machines accessed by multiple users, since this makes accountability extremely difficult.
Each user should have their own account, following the principle of least privilege to prevent unauthorized software execution. Additionally, it is advisable to restrict and monitor the use of remote access tools such as AnyDesk or TeamViewer. Unexpected installations or executions of these tools should be treated as high-priority alerts.
To minimize the impact of ransomware, educational institutions should improve their backup and recovery strategy. Backups should be isolated from the primary environment (preferably in more than one location) and tested regularly. Centralized logging, extended EDR telemetry retention, and proper time synchronization across hosts can also improve the ability to reconstruct an attack timeline and implement the necessary response measures.
The use of outdated systems increases the attack surface, so we recommend that organizations adopt an effective update and patch management policy. It is also important to raise security awareness, since users must understand the risks associated with credential sharing, unknown executables, and unauthorized software.
From a digital forensics and incident response (DFIR) perspective, the reviewed incidents demonstrate that effective incident response activities require correlating multiple forensic artifacts in order to reconstruct the attacker’s actions. Investigators should be aware of how to find information even when logs are missing. Many other artifacts are preserved and can be used for this purpose, such as Amcache, PCA, Prefetch, UserAssist, MFT, and USN Journal. The attackers may fail to erase all traces of their activity, so taking a broad forensic approach is of the utmost importance for determining the scope of the compromise and supporting containment and remediation actions.
Observed TTPs
The table below shows the observed TTPs in our dataset, including cases not detailed in this post.
Phishing played a part in more than half of all incident response engagements undertaken by Talos, Cisco's threat research organization, during the second quarter of 2026, with healthcare organizations and manufacturing firms among the top targets.
Phishing was the primary means of gaining initial access this quarter, appearing in over half of all Cisco Talos Incident Response (Talos IR) engagements – an increase from approximately a third of engagements last quarter. Attackers continued to innovate their delivery methods to evade defenses, deploying QR code-embedded PDFs to bypass traditional email gateways and hosting links on trusted cloud platforms. We also saw a spike in authentication abuse this quarter — observed in 65 percent of engagements compared to 35 percent last quarter — with attackers frequently bypassing or defeating multi-factor authentication (MFA) using adversary-in-the-middle (AitM) proxies, session-token theft, MFA fatigue attacks, and self-enrolled devices, amongst other methods.
Ransomware incidents made up over 20 percent of engagements this quarter, similar to just under 20 percent last quarter. Talos IR responded to Sinobi ransomware for the first time, as well as previously seen variants Nitrogen and Warlock. We observed ransomware operators leveraging legitimate remote monitoring and management (RMM) tools, such as trojanized MeshAgent binary and Zoho Assist, for stealthy access, requiring defenders to prioritize behavior-based monitoring and strict control over administrative binaries.
In the latest Talos Threat Perspective episode, we explore these trends, and highlight where defenders have the best opportunities to detect attackers:
QR phishing campaign leverages trusted infrastructure to target Australian organizations
Starting in April, we observed a persistent QR code phishing campaign targeting primarily Australian organizations that leverages compromised Microsoft 365 accounts to harvest credentials and propagate the attack via internal contact lists. The campaign, which remained ongoing as of late June 2026, employs auto-generated, victim-tailored PDF documents containing QR codes that direct to adversary-controlled M365 credential harvesting pages. If credentials are successfully captured, the adversary attempts access to the victim’s Microsoft account and conducts various post-compromise actions including creating email inbox rules for defense evasion, leveraging SharePoint to host malicious documents, and sending additional internal and external phishing emails to continue the compromise chain.
We assess with high confidence that the threat actor, who we have dubbed UAT-11764, will almost certainly continue leveraging this QR code phishing operation, using each newly compromised mailbox's contact lists to expand its reach and sustain the campaign's momentum. By weaponizing existing, trusted infrastructure like SharePoint and M365, UAT-11764 can bypass many standard email security gateways. As such, network defenders should implement policies that block or flag emails containing QR codes within PDF attachments, enforce phishing-resistant MFA on M365 accounts, and monitor for suspicious inbox rule creation and anomalous SharePoint file staging as indicators of post-compromise activity.
ARToken platform provides toolkit for Microsoft 365 account compromise
Talos uncovered a phishing-as-a-service (PhaaS) operator platform, ARToken, in an engagement this quarter that is closely linked to the EvilTokens platform. According to our analysis, the ARToken panel exposes 80+ API endpoints for device code phishing, primary refresh token (PRT) persistence, email access, business email compromise (BEC) operations, and SharePoint exfiltration — all accessible to operators through a React-based dashboard. Our investigation into the platform found phishing lures that impersonate trusted vendors and abuse legitimate Microsoft services, allowing attackers to bypass MFA through the OAuth device authorization flow rather than stealing passwords.
ARToken extends beyond a typical phishing kit by providing affiliates with a comprehensive post-compromise toolkit. We observed capabilities including automated token management, persistent access through PRTs, OneDrive and SharePoint administration, geo-dynamic templates, inbox rule manipulation, cross-account keyword monitoring, and collaborative token sharing. We also identified advanced anti-analysis techniques, including layered evasion mechanisms and encrypted client-side payloads, highlighting the increasing sophistication of modern PhaaS platforms and reinforcing the need for organizations to monitor device code authentication, enforce Conditional Access policies, and strengthen defenses against token-based attacks.
Ransomware trends
Ransomware and pre-ransomware incidents made up over 20 percent of engagements this quarter, relatively similar to just under 20 percent last quarter. As previously mentioned, Talos IR responded to Sinobi ransomware for the first time, as well as previously seen variants Nitrogen and Warlock. We observed operators from these groups leveraging tools not previously identified in public reporting, including a trojanized MeshAgent binary and Zoho Assist for remote access.
Sinobi ransomware operators weaponize MeshAgent for covert backdoor access
We responded to a Sinobi ransomware engagement for the first time in April; while this ransomware-as-a-service (RaaS) operation emerged nearly a year ago, there has been minimal public reporting on the actors’ operations.
Notably, we observed the threat actors use a trojanized MeshAgent binary as their primary C2 mechanism during this engagement, a tactic that has not been previously associated with the group in public reporting. MeshAgent is the open-source agent component of the MeshCentral remote management platform. Here, the actor weaponized it into a covert durable backdoor installed as a SYSTEM-level auto-start service, communicating over encrypted WebSocket (WSS) to an attacker-controlled server. This approach allowed the actor to blend malicious traffic with legitimate remote management activity and maintain undetected access for approximately three days before ransomware deployment.
Following C2 establishment, the actor moved laterally through the network using RDP and WinRM, leveraging a service account with a weak, easily cracked password obtained from the domain credential store, ntds.dit. The actor ultimately deployed the ransomware across the entire domain using a malicious Group Policy Object (GPO) logon script. The incident resulted in the encryption of systems with the .SINOBI file extension, alongside observed data exfiltration staging activity conducted via rclone.exe.
Looking forward, Sinobi operators will likely continue weaponizing legitimate tools like MeshAgent because these binaries blend into standard administrative traffic and bypass many traditional signature-based alerts. The use of GPO-based deployment scripts suggests an understanding of enterprise architecture, and operators will likely continue to exploit centralized management features to ensure rapid, domain-wide encryption. Defenders should prioritize monitoring of administrative tools and implement strict application allowlisting to prevent unauthorized binaries from running as services. Further, proactive hunting for unauthorized MeshAgent instances and auditing service account permissions may help in identifying and disrupting Sinobi activity before encryption.
Warlock actors deploy Zoho Assist to attempt remote access without active user sessions
In one engagement, we observed Warlock ransomware operators (also known as Storm-2603) deploying an installer for the RMM tool Zoho Assist Unattended Agent, which is designed to allow administrative remote control of an endpoint without a user logged in. The tool, which we have not previously seen attributed to Warlock, enables the attackers to maintain persistent, stealthy, and unrestricted control, significantly increasing the potential malicious impact of an incident.
While the activity in this particular did not lead to encryption, it was consistent with a successful Warlock ransomware attack Talos observed in May. To counter this threat, organizations must shift from signature-based detection to behavior-based monitoring, focusing on the specific tactics, techniques, and procedures (TTPs) utilized by Storm-2603, such as the abuse of legitimate administrative tools and rapid movement within the network.
Targeting
For the second quarter in a row, health care led as the most targeted industry vertical accounting for 17 percent of all engagements, with public administration and manufacturing following at 14 percent each. A shared characteristic of these top-targeted sectors is a critical lack of downtime tolerance. The vast majority of targeted health care organizations were entities that directly support clinical operations and/or diagnostic services, where service interruption can result in operational and patient-care consequences. Almost all targeted public administration organizations were local governments, which provide essential public services, while the targeted manufacturing entities represented high-value targets within the industrial supply chain, where potential disruptions could create cascading effects across the downstream technology and energy sectors.
Initial access
As mentioned, phishing was the top means of gaining initial access this quarter, accounting for over half of engagements where initial access could be determined — an increase from 35 percent last quarter. Many phishing engagements included MFA-bypass techniques, such as OAuth device-code phishing and AiTM frameworks, allowing adversaries to intercept session tokens. Other observed means of achieving initial access included exploitation of public-facing applications and drive-by compromise.
Recommendations for addressing top security weaknesses
Implement properly configured, phishing-resistant MFA and tighten authentication controls
Authentication abuse was the most prevalent security weakness this quarter, observed in 65 percent of engagements — up sharply from 35 percent last quarter. Adversaries consistently defeated or bypassed MFA using AitM proxies and session-token theft, MFA fatigue attacks, registration of attacker-controlled devices for authentication, and legacy authentication protocols that circumvent MFA altogether. To reduce this risk, Talos IR recommends transitioning from push- and SMS-based MFA to phishing-resistant methods such as FIDO2/WebAuthn and hardware security keys. Organizations should also restrict self-service MFA enrollment by requiring helpdesk verification, block legacy authentication through Conditional Access, enforce number matching or verified push where phishing-resistant methods are not yet feasible, and condition access on device compliance and trusted infrastructure rather than geographic location alone.
Configure centralized logging with adequate retention across the environment
Insufficient logging and visibility was the second most common weakness, observed in 42 percent of engagements compared to 18 percent last quarter. Deficiencies included domain controller security logs retained for only a few hours, host event logs truncated or overwritten before capture, absent NetFlow that prevented reconstruction of external authentication and exfiltration, on-device-only logs that adversaries deleted to evade detection, and short cloud-telemetry retention that did not extend back to the true initial-access date. In several engagements these gaps prevented definitive determination of the initial access vector or the scope of data exfiltration. Talos IR recommends implementing a SIEM or centralized logging platform with a minimum of 90 days of retention, forwarding logs from servers, workstations, network infrastructure, cloud identity providers, and security appliances off-device so they survive log tampering and host rebuilds, and enabling process-creation, command-line, and cloud API (e.g., Microsoft Graph) auditing. Talos IR's Log Architecture Assessment service can identify gaps and provide a roadmap to a complete view of the environment.
Conduct robust patch management and reduce exposed infrastructure
Vulnerable, exposed, or unpatched internet-facing infrastructure was the third most common weakness, observed in 31 percent of engagements, similar to last quarter’s 25 percent. A variety of different vulnerabilities were targeted including ToolShell, an older Telerik UI deserialization flaw, and SD-WAN and perimeter-VPN appliance CVEs. Internet-exposed services were also subjected to SQL-injection and denial-of-service activity. Talos IR recommends identifying and prioritizing the patching or decommissioning of all end-of-life and externally exposed systems, isolating systems that cannot be immediately upgraded, restricting management plane and remote access services behind a VPN or trusted source, deploying a Web Application Firewall (WAF) with rules for known exploitation patterns, and establishing a vulnerability management process capable of rapidly identifying and patching exposed assets — particularly given the accelerating reduction in time between vulnerability disclosure and exploitation.
Enforce strict outbound email thresholds to disrupt attack propagation
Finally, unlimited outbound email thresholds were a notable security weakness this quarter, enabling threat actors to propagate malicious activity in almost 15 percent of engagements. Though not as prevalent as the above weaknesses, it was more frequently observed than in previous quarters and warrants mention. For example, in one engagement, a user clicked on a malicious phishing email that led to credential theft and account compromise. Shortly after the threat actors gained access to the user’s mailbox, they sent over 6,600 phishing and spam emails to continue the attack chain. The failure to contain the compromise via outbound rate limiting significantly amplifies the damage of a single compromised credential; implementing these controls is a low-effort, high-impact mitigation strategy that effectively disrupts the attack chain.
Top-observed MITRE ATT&CK techniques
The table below represents the MITRE ATT&CK techniques observed in this quarter’s Talos IR engagement. Given that some techniques can fall under multiple tactics, we grouped them under the most relevant tactic in which they were leveraged. Please note this is not an exhaustive list.
Key findings from the MITRE ATT&CK framework include:
Consistent with phishing being a top threat this quarter, email hiding rules was the most observed tactic for persistence while internal spearphishing was most seen for lateral movement.
Use of valid accounts was frequently observed for both privilege escalation and persistence, highlighting how identity abuse remains a key theme across engagements.
Actors also relied on legitimate tools and web protocols to challenge detection, abusing native email features and cloud APIs, relying on standard web protocols for C2, and using valid administrative credentials for RDP and SSH.
Tactic
Technique
Example
Reconnaissance (TA0043)
T1598 Phishing for Information
Adversaries may send phishing messages to elicit sensitive information that can be used during targeting. Phishing for information is an attempt to trick targets into divulging information, frequently credentials or other actionable information.
T1595 Active Scanning
Adversaries may execute active reconnaissance scans to gather information that can be used during targeting.
T1593 Search Open Websites/Domains
Adversaries may search open websites and domains to gather information about a victim that can be used during targeting.
T1589 Gather Victim Identity Information
Adversaries may gather information about the victim's identity that can be used during targeting.
Initial Access (TA0001)
T1566 Phishing
Adversaries may send phishing messages to gain access to victim systems.
T1190 Exploit Public-Facing Application
Adversaries may exploit a vulnerability to gain access to a target system.
T1078 Valid Accounts
Adversaries may use compromised credentials to access valid accounts during their attack.
Execution (TA0002)
T1204.001 User Execution: Malicious Link
An adversary may rely upon a user clicking a malicious link in order to gain execution. Users may be subjected to social engineering to get them to click on a link that will lead to code execution.
T1078 Valid Accounts
Adversaries may obtain and abuse credentials of existing accounts to access systems within the network and execute their payload.
Persistence (TA0003)
T1564.008 Hide Artifacts: Email Hiding Rules
Adversaries may use email rules to hide inbound emails in a compromised user's mailbox. Many email clients allow users to create inbox rules for various email functions, including moving emails to other folders, marking emails as read, or deleting emails.
T1663 Remote Access Software
Adversaries may use legitimate remote access software, such as VNC, TeamViewer, AirDroid, AirMirror, etc., to establish an interactive command and control channel to target mobile devices.
T1053 Scheduled Task/Job
Adversaries may abuse task scheduling functionality to facilitate initial or recurring execution of malicious code.
T1133 External Remote Services
Adversaries may leverage external-facing remote services to initially access and/or persist within a network. Remote services such as VPNs, Citrix, and other access mechanisms allow users to connect to internal enterprise network resources from external locations.
T1078 Valid Accounts
The adversary may compromise a valid account to move through the network to additional systems.
Defense Impairment (TA0112)
T1687 Exploitation for Defense Impairment
Adversaries may exploit vulnerabilities in security software, infrastructure, or defensive components to degrade, disable, or otherwise continue to impair their ability to prevent, detect, or respond to malicious activity.
T1078 Valid Accounts
Adversaries may obtain and abuse credentials of existing accounts as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion.
T1484 Domain or Tenant Policy Modification
Adversaries may modify the configuration settings of a domain or identity tenant to evade defenses and/or escalate privileges in centrally managed environments.
Stealth (TA0005)
T1564.008 Hide Artifacts: Email Hiding Rules
Adversaries may use email rules to hide inbound or outbound emails in a compromised user's mailbox.
T1070 Indicator Removal
Adversaries may delete or modify artifacts generated within systems to remove evidence of their presence or hinder defenses.
Credential Access (TA0006)
T1111 Multi-Factor Authentication Interception
Adversaries may target MFA mechanisms, (i.e., smart cards, token generators, etc.) to gain access to credentials that can be used to access systems, services, and network resources.
Adversaries may attempt to bypass MFA mechanisms and gain access to accounts by generating MFA requests sent to users.
T1110.003 Brute Force: Password spraying
Adversaries may use a single or small list of commonly used passwords against many different accounts to attempt to acquire valid account credentials.
Discovery (TA0007)
T1018 Remote System Discovery
Adversaries may attempt to get a listing of other systems by IP address, hostname, or other logical identifier on a network that may be used for Lateral Movement from the current system.
T1083 File and Directory Discovery
Adversaries may enumerate files and directories or may search in specific locations of a host or network share for certain information within a file system.
T1087 Account Discovery
Adversaries may attempt to get a listing of valid accounts, usernames, or email addresses on a system or within a compromised environment.
T1082 System Information Discovery
An adversary may attempt to get detailed information about the operating system and hardware, including version, patches, hotfixes, service packs, and architecture.
T1526 Cloud Service Discovery
An adversary may attempt to enumerate the cloud services running on a system after gaining access.
Adversaries may use Valid Accounts to log into a computer using the Remote Desktop Protocol (RDP). The adversary may then perform actions as the logged-on user.
T1534 Internal Spearphishing
After they already have access to accounts or systems within the environment, adversaries may use internal spearphishing to gain access to additional information or compromise other users within the same organization.
T1021.004 Remote Services: SSH
Adversaries may use Valid Accounts to log into remote machines using SSH. The adversary may then perform actions as the logged-on user.
Command and Control (TA0011)
T1219 Remote Access Software
An adversary may use legitimate remote access tools to establish an interactive command and control channel within a network.
T1071.001 Application Layer Protocol: Web Protocols
Adversaries may communicate using application layer protocols associated with web traffic to avoid detection/network filtering by blending in with existing traffic.
T1102 Web Service
Adversaries may use an existing, legitimate external Web service as a means for relaying data to/from a compromised system.
T1572 Protocol Tunneling
Adversaries may tunnel network communications to and from a victim system within a separate protocol to avoid detection/network filtering and/or enable access to otherwise unreachable systems.
Exfiltration (TA0010)
T1567 Exfiltration Over Web Service
Adversaries may use an existing, legitimate external Web service to exfiltrate data rather than their primary command and control channel.
T1048 Exfiltration Over Alternative Protocol
Adversaries may exfiltrate data over a different protocol than the command and control channel.
Impact (TA0040)
T1486 Data Encrypted for Impact
Adversaries may use ransomware to encrypt data on a target system.
Kenya is investigating a Kenya cyberattack that temporarily defaced President William Ruto’s official website with an anti-government message and a Bitcoin ransom demand for five bitcoins, reportedly worth about $330,000. The attackers replaced the website’s homepage with the message, displayed a cryptocurrency wallet address and threatened to publish unspecified information about President William Ruto unless the ransom was paid.
The website was hacked on Saturday, July 18, 2026. Following the incident, access to the presidential website was temporarily restricted as authorities began containment, forensic analysis and restoration efforts. According to local media reports, access to the website was restored by Monday.
Kenya Cyberattack Prompts Incident Response
Kenya’s Ministry of Information, Communications and the Digital Economy confirmed that the official website of the President had been affected by a cybersecurity incident.
The ministry said that after the incident was detected, the ICT Authority immediately activated established cybersecurity incident response protocols.
As a precautionary measure, access to the presidential website was temporarily restricted to facilitate containment, forensic analysis and restoration efforts.
The ministry said appropriate mitigation measures had since been implemented and that restoration of the website was underway.
[caption id="attachment_113245" align="aligncenter" width="600"] Source: Kenya’s Ministry of Information, Communications and the Digital Economy[/caption]
At the time of the statement, the government said there was no evidence of unauthorized access to sensitive data, data exfiltration or loss of information. It also stated that government systems and digital services remained secure and operational.
The ICT Authority is working with relevant government agencies and technical partners to conduct a comprehensive forensic investigation and establish the full circumstances surrounding the incident.
Kenya President William Ruto Cyberattack Investigation
The Kenya President William Ruto cyberattack involved the defacement of the president’s official website. The attackers replaced the homepage with an anti-government message, displayed a cryptocurrency wallet address and demanded five bitcoins.
The attackers also threatened to publish unspecified information about President William Ruto if the ransom was not paid.
The government has not reported evidence of unauthorized access to sensitive data or data exfiltration. The ongoing forensic investigation is expected to establish the circumstances surrounding the incident and determine the extent of the attack.
Kenya Government Website Hack Follows Earlier Incidents
The latest Kenya government website hack follows previous cyber incidents involving government digital services and websites.
In July 2023, Kenya’s eCitizen platform, which is used for dozens of public services, was disrupted by a cyberattack. The incident affected agencies including the National Transport and Safety Authority and Kenya Power.
On November 17, 2025, hackers launched a coordinated attack on several government websites, including the presidency’s portal. The websites were temporarily knocked offline, while some pages were replaced with extremist messages.
According to the information provided by local media, the government later blamed a group calling itself PCP@Kenya, restored the affected platforms and promised stronger cyber defences.
The latest incident involved a Bitcoin ransom demand for five bitcoins, reportedly valued at approximately $330,000. The attackers displayed a cryptocurrency wallet address and threatened to release unspecified information about the president.
It remains unclear from the available information whether the attackers accessed systems or data beyond the presidential website. The Kenyan government has said there is currently no evidence of unauthorized access to sensitive data, data exfiltration or loss of information.
The ICT Authority and relevant government agencies are continuing their forensic investigation to establish how the incident occurred and determine the full circumstances surrounding the Kenya cyberattack.
Hugging Face says an autonomous AI agent carried out a cyberattack against its production systems, highlighting the growing role of AI in offensive and defensive cybersecurity.
The following analysis presents the key findings from Kaspersky Compromise Assessment engagements performed in 2025. A compromise assessment is an independent, expert-driven service that examines whether a target network has been compromised. The service combines threat intelligence analysis (including darknet sources), tool-aided endpoint scanning, a systematic review of security event logs and network traffic, and, when necessary, an initial incident response and digital forensic investigation.
This report focuses on missed incidents – threats that remained undetected for weeks, months, or even years.
Key trends observed during compromise assessment engagements
Proactive compromise assessment decreases the number of missed high-severity incidents. The highest proportions of high-severity incidents were revealed in organizations that requested our compromise assessment service after containing a known incident. The lowest proportions of high-severity incidents were observed in organizations that conducted regular audits. Of all the incidents discovered, 20% were found manually, while enterprises missed 60% because of the absence of high-confidence alerts from the tools in place.
Nearly a third of discovered incidents took over three months to detect. The longer a threat persisted in the target environment, the greater the likelihood that an incident would be severe. 30.8% of all discovered incidents and 52% of high-severity compromises had historical activity spanning over three months. The oldest incident discovered in 2025 had gone undetected for four years.
Malicious files often remain in backups and are restored after incident response activities. 40% of all discovered web shells resided in backups and went unnoticed until a proper compromise assessment was conducted.
Threat actors rely on remote management tools and LoLBins. These types of tools were found in all compromise assessment engagements that resulted in an incident detection.
Monitoring tools and controls are not self-sufficient; operational maturity makes the difference. Monitoring tools must be configured and adapted to the changing threat landscape. Furthermore, human analysts need to review low-confidence alerts. A lack of continuous monitoring and threat hunting activities increased the likelihood of high- and medium-severity incidents to 84–86%. At the same time, high‑severity incidents were rare among organizations with in-house capabilities to reverse-engineer malware.
Communication issues lead to missed incidents. Nearly a third of the compromise assessments revealed communication issues that impacted incident response activities.
The incident response playbook is not set in stone. For incident response to be efficient and effective, playbooks must be updated as new artifacts are discovered. Treating the incident response plan as a living document reduces the risk of missing threats.
About the Kaspersky Compromise Assessment service
Our global compromise assessment portfolio spans several regions. In 2025, around 71% of the incidents we identified affected our customers in the META region, while the APAC and CIS regions accounted for the remaining 29%.
Geographic distribution of incidents identified during Kaspersky Compromise Assessment projects in 2025 (download)
Our service was requested by organizations from a diverse set of sectors. The government sector accounted for around 29% of incidents, followed by the education (19%) and financial (17%) sectors.
Distribution of economy sector incidents identified during Kaspersky Compromise Assessment projects in 2025 (download)
Detection logic families
Our compromise assessments operate on a continuously updated catalogue of indicators of attack (IoAs). Because the raw set of IoAs is too granular for high-level reporting, we map them to a concise set of detection logic families. The statistics indicate that three detection families dominate the incident mix:
Credentials from dumps: 12.4% of all incidents;
Specific living-off-the-land (LOTL) tools: 11.2 %;
Specific malware families: 11.2 %.
These three detection logic families represent high-fidelity indicators of attack that reliably signal infrastructure compromises ranging from dormant, disk-based malware to persistent and multi-stage attacks.
Distribution of detection logic families (download)
Reasons for requesting Kaspersky Compromise Assessment services
Analysis of our compromise assessment engagements that took place in 2025 reveals a clear correlation between the stated purpose of the engagement and the risk profile of the findings. General audits dominate the portfolio with 56% of requests, followed by authority reporting engagements (19%), post-incident checkups (17%), and acquisitions (9%).
Statistics on the reasons behind CA project requests (download)
When the findings are classified by severity, the post-incident checkup category exhibits the highest proportion of high-severity incidents (40.7%). The full breakdown is shown below.
Incident severity breakdown by service engagement reason
Incident severity (%)
High
Medium
Low
Reason for service
Acquiring new company
28.6
42.8
28.6
General audit
27.7
36.7
35.6
Report to an authority
30
46.7
23.3
Checkup after a cybersecurity incident
40.7
25.9
33.4
Post-incident checkups are frequently initiated after an initial incident response (IR) effort. The elevated share of high-severity findings suggests that IR activities, which are typically limited to containing a known incident, do not provide a complete view of the broader environment. Consequently, other threats may remain undetected until a full compromise assessment is performed.
Merger and acquisition-related assessments are proactive assessments performed when a company acquires another entity. This involves the target’s network being scanned for hidden threats before the two environments are merged. These assessments demonstrate a balanced distribution of severity: 28.6% low-severity, 42.8% medium-severity, and 28.6 % high-severity. This reflects the mixed risk posture of target environments of acquisitions, which are often evaluated for both known vulnerabilities and hidden malicious activity. Similarly, other proactive approaches like general audit assessments or assessments driven by the need to regularly submit a compliance report to a regulatory authority, share almost the same ratio. This indicates that regular, proactive and compliance-oriented assessments tend to reveal substantive issues earlier in the attack lifecycle, reducing the likelihood that they will evolve into high-severity incidents.
Organizations that conduct regular audits have the highest rate of low-severity findings (36%) and the lowest rate of high-severity issues (28%). We can assume with medium confidence that continuous, proactive compromise assessments are more effective at limiting the emergence of high-severity compromises than reactive, incident-driven evaluations. The data collected in 2025 are consistent with this hypothesis. Integrating regular, third-party compromise assessments into governance processes can therefore reduce the probability of unexpected high-severity findings and improve overall risk posture.
The following case study illustrates the impact of relying on a reactive rather than proactive approach. It describes a persistent threat that remained dormant on a client’s network and was only discovered after a comprehensive compromise assessment was performed following initial IR activity.
Case study: Dormant threat uncovered only by a compromise assessment
A midsize enterprise suffered a high-severity intrusion that was contained and remediated by the IR team within the defined scope of the initial alert. Following containment, the organization requested a check to determine if any additional footholds existed elsewhere in the network. To address this need, the organization engaged Kaspersky’s Compromise Assessment (CA) service, which performed a full forensic review of the environment beyond the scope of the initial incident.
Compromise assessment experts collected forensic metadata, historical security event logs, and Active Directory configuration data from the entire infrastructure. Threat hunting queries were executed against the aggregated telemetry, focusing on persistence mechanisms, lateral movement artifacts, and anomalous process activity. As a result, a number of severe threats were detected and reported; for example, malicious persistence:
A cron job that recreates a web shell
A critical Linux system (web server) had a cron job that automated fetched a copy of a PHP web shell from a public GitHub repository and placed it in an online directory. Even if the file was removed by security personnel, the cron job would simply download it again, giving the attacker a persistent remote code execution point on the web server.
A live reverse shell
On a server hosting a published web application, the process list showed a bash reverse shell.It was run by a user with the username “apache,” which was the account used to run the web application. This may indicate that the attacker exploited a vulnerability in the web application to gain remote code execution, allowing them to establish a reliable command and control channel that bypassed the firewall because it was initiated from inside the network.
ClipBanker data stealer persisting via Windows registry
A ClipBanker variant was detected on a user’s workstation machine maintaining persistence by adding itself to the registry key HKU\S-1-5-21-[REDACTED]-500\Software\Microsoft\Windows\CurrentVersion\Run\9Er6IIp.
This was done after adding the malware’s folder to Windows Defender exclusions and applying hidden and system attributes to the file to hide it from regular users.
Malicious WMI event consumer with deceptive alias
A malicious WMI event consumer was detected that downloads and executes a PowerShell script. It created the alias “Kaspersky” for “Invoke-Expression” in an attempt to blend in as legitimate activity in the hope that a quick glance at the script would not raise suspicion. Kaspersky’s Cyber Threat Intelligence confirmed that the downloaded script (no longer reachable) was a weaponized payload used to spread the infection further.
The IR containment was rapid, focused and effective in addressing the specific incident that triggered the alert. However, the broad-scope compromise assessment revealed multiple backdoors across the environment, each using a different persistence technique: cron jobs, scheduled registry runs, and WMI subscriptions. The infected hosts were outside the original IR scope, so they remained unseen until a comprehensive hunt was conducted.
Incident response excels at stopping the bleeding and ensuring business continuity after a known incident. A compromise assessment provides a health check that determines whether any other wounds exist. By pairing timely IR with regular, full network compromise assessments, the organization had both the reactive agility to contain incidents and the proactive visibility to eradicate malicious persistence wherever it was hiding. The investigation uncovered additional undetected footholds, providing a clearer view of the environment and reducing the likelihood of a repeat incident.
Missed long-term incidents
The statistics on the mean time to detect (MTTD) incidents identified during compromise assessment projects are concerning. Many incidents go unnoticed for extended periods. For example, in 2025 we identified an incident that was approximately four years old!
Such prolonged detection times can lead to severe consequences, as 30.8% of incidents have historical activity spanning over three months. These incidents can range from dormant malware to persistent threats, highlighting the need for robust detection and response mechanisms.
Severity distribution of incidents by MTTD (download)
The relationship between detection latency and incident severity was analyzed by grouping findings according to their MTTD:
For incidents detected within the first month, severity is more or less evenly distributed among the low, medium and high categories.
However, as the MTTD increases, the severity of incidents shifts towards higher severity. Notably, a high proportion of incidents that took between 30–60 days to be detected are medium-severity incidents (78.57%), while those detected between 60–90 days are predominantly high-severity (71.43%).
Among incidents detected after 90 days, a significant proportion are also high-severity incidents (52%).
Overall, 52% of high-severity incidents are only identified after 90 days of going undetected. This represents a concrete risk: the longer an incident goes undetected, the higher the probability of severe compromise. Organizations that integrate continuous detection, threat hunting activities, and regular compromise assessments can reduce MTTD, limit threat escalation, and lower their overall risk profile.
The following case study highlights the importance of timely detection and response to prevent incidents from escalating into high-severity events.
Case study: Four-year-old crypto mining activity on domain controllers
In May 2025, our compromise assessment experts identified three domain controllers on a customer network that were infected with malicious files. The files had remained hidden for almost four years. They were created in the C:\Windows\Fonts\Mysql directory, abusing its unique characteristic whereby only font files in this directory are visible to regular users. Files with the names nei.bat, dl1host.exe, bat.bat, cmd.bat, and a spoofed svchost.exe were found there. These files were created in June and July of 2021.
Kaspersky Threat Intelligence confirmed that these files are part of a crypto-mining campaign called NSABuffMiner, which spreads via the SMB protocol by exploiting the EternalBlue (MS17-010) vulnerability. A patch was released for this vulnerability in March 2017, four years before the initial compromise. This was more than enough time to patch the systems. This underscores the importance of implementing effective patch management operations and staying informed through threat intelligence news feeds.
Based on the organization’s request, the malicious files were collected along with a forensic image for analysis and revealed the following:
bat.bat and cmd.bat generate random IPs and scan them with a lightweight port scanner renamed taskhost.exe to locate live hosts with SMB port 445 and NetBIOS port 139 open and looking for vulnerable machines.
Discovered vulnerable IPs are handed to helper scripts named bat, poab.bat, load.bat, and loab.bat that execute the malware mance.exe, Eter.exe, and puls.exe to inject the malicious DLLs Eternalblue2.dll and Doublepulsar2.dll into lsass.exe and explorer.exe, enabling lateral movement.
Persistence is then established by creating scheduled tasks to execute the propagation and infection scripts, and services are created to execute the crypto miner, with the names MicrosoftMysql, MicrosoftFonts, and MicrosoftMSSql. Other scheduled tasks were also observed with the names At1 and At2 and created for the same purpose.
After successfully compromising the machine and installing the persistence mechanisms, a cleanup task is performed to delete temporary files and dropped malware.
Because of the lack of proper monitoring and threat hunting procedures, the organization was unaware that a mining operation had been hijacking their resources for four years, running on their domain controllers.
Unintentional malware preservation
An issue that is frequently discovered during compromise assessment activities is that of web shells remaining or being restored on target systems. Based on data collected during 2025 compromise assessment engagements, 64% of web shell incidents were classified as high-severity findings, 7% as low-severity (possibly legitimate files, but potentially compromised), and 29% as medium-severity findings requiring eradication.
Web shell incident distribution by severity (download)
One way web shells persist is through infected backups. The distribution of discovered incidents in our projects shows that 60% of the web shells were located on active systems, while 40% were stored in backups. Restoring such backups can reintroduce the threat long after the initial infection.
Another common issue is asset inventory gaps, which were observed in 25% of engagements. This resulted in untracked devices, particularly cloud-only Linux web servers that are not joined to Active Directory, evading routine scans.
An attacker can plant a web shell on such a cloud server, and that server never appears in the inventory, though is still regularly backed up. As a result, the web shell may persist on the cloud server for a long time. If it is occasionally deleted, the backup server later restores the infected files, exposing the web shell to third parties again. This demonstrates that without a complete and up-to-date asset inventory, detection capabilities are significantly impaired.
One case was observed in which the web shell was located on an internal file server (not a web server) within a .rar archive at the following path: D:\backup\[redacted_for_privacy].rar/wwwroot/<…>/[redacted_for_privacy].aspx
During the investigation, the server administrators indicated that the folder had been copied from a different server that was offline at the time of the assessment. Because of poor asset inventory, the company’s security team did not detect the infection of this server. As a result of the backup procedure, the web shell was copied to the internal file server. Forensic analysis of the offline server revealed that the adversary had introduced a backdoor to the majority of the Windows servers in the environment, configuring the local administrator account with an identical password.
The technique involved using PsExec to execute a .cmd script across all the servers listed in a .txt file; the script altered the local administrator password to a common value:
Legitimate, yet suspicious: LoLBins and remote management tools
In 2025, nonstandard remote management (RM) utilities were observed in all compromise assessment engagements. Living-off-the-land binaries (LoLBins) were also present in every engagement. These findings highlight the ongoing challenge for security operations centers (SOCs) that must distinguish between legitimate administrative use and malicious abuse.
The observed remote management utilities span both proprietary platforms, such as TeamViewer and AnyDesk, and freely available tools, including PsExec, VNC servers, and open-source RM frameworks. These binaries are used daily in many environments for troubleshooting, software deployment, or remote support. However, the same capabilities – creating a new local admin account, copying files to a remote share, or launching a network port scan for diagnostics – are also typical of attacker post-exploitation activity. Our analysts frequently encounter cases where a legitimate sysadmin action resembles a lateral movement step. This makes the mere fact that “a remote management tool was executed” insufficient to classify it as an incident. Instead, the incident must be judged against an organization-specific baseline of expected usage. Establishing that baseline requires a deep, contextual understanding of who is authorized to run the tool, from which endpoints, and under which circumstances – a resource-intensive process on a case-by-case basis.
LoLBins, binaries that are part of the operating system or commonly installed utilities (such as certutil, bitsadmin, regsvr32, and wmic), were also present in every assessment. While these files are trusted system components, threat intelligence confirms they are often repurposed for lateral movement, data exfiltration, and persistence. The graph below shows the severity distribution for incidents involving riskware or a LoLBin binary. The relatively high share of medium- (40%) and high-severity (31%) findings underscores that misuse of legitimate utilities is often the vector that enables a compromise to progress beyond the initial foothold.
Severity distribution of incidents involving riskware or LoLBin involvement (2025) (download)
To address the potential use of LoLBins and remote management tools by attackers, we recommend a multi-layered approach that goes beyond static deny lists:
Formalize a policy that enumerates the remote management tools authorized for use. The policy must be coupled with a requirement to forward software operational logs to a central log management platform (SIEM or dedicated log collector). Continuous monitoring of these logs enables a SOC to detect deviations from authorized usage patterns.
Periodically perform a software inventory audit to identify unauthorized remote management tools. Consider collecting data from the following registry keys on all hosts:
Enrich the hashes (MD5/SHA-256) of every executed binary with a functional category, such as “Remote Access”, “Golden Image”, or “Security Software.” Correlating the category with the execution path makes it possible to hunt for instances where a “Remote Access” binary runs from a non-standard location, such as %TEMP% or a user’s Downloads folder.
Deploy detection rules that capture known LoLBin abuse patterns, such as certutil -decode, bitsadmin -transfer, regsvr32 -i <dll>, wmic process call create. These rules should be continuously baselined against the organization’s normal activity. The baseline is derived from a period of verified legitimate use and refreshed whenever new legitimate use cases emerge. Alerts are generated only when observed behavior diverges from the established norm, thereby reducing noise while preserving sensitivity to genuine abuse.
Impact of not having continuous monitoring and proactive threat hunting
Analyses of recent compromise assessment projects reveal a systematic blind spot in organizations that follow the security-by-purchase model to defend their networks. Without continuous human monitoring or a dedicated threat hunting program, the severity profile of detected incidents becomes heavily skewed toward a higher impact:
Incident severity breakdown, where 24/7 monitoring or threat hunting is absent
Control type
Low-severity
Medium/high-severity
No continuous monitoring
14%
86%
No threat hunting
16%
84%
Often, the problem is not a lack of tools, but rather a lack of operational use of those tools. Many enterprises deploy next-generation security solutions and then let them run in “set-and-forget” mode, or they rely exclusively on an alert-driven workflow. The following issues are common in such organizations:
Alert fatigue: high false positive rates drown analysts in noise, forcing them to triage superficial indicators rather than conduct deep, contextual investigations.
Fragmented analyst assignment: without a dedicated hunting team, the same analyst may be tasked with dozens of unrelated alerts, limiting the time available for the hypothesis-driven exploration required to uncover stealthy footholds.
The practical consequence is that adversaries retain an extended dwell time, enabling continued lateral movement and data exfiltration before the organization becomes aware of the breach. This pattern represents a measurable risk exposure that translates directly into business impact. As the following example illustrates, merely purchasing security controls does not guarantee detection; continuous monitoring, regular alert validation, and structured threat hunting are essential to reduce dwell time and limit business impact.
Case study: Secure by design without continuous monitoring
The enterprise invested in security controls and assumed that the environment was secure by design. However, security controls require proper configuration, continuous tuning, and active monitoring to be effective. The tools had been installed, but no one was ensuring that the security controls were configured effectively, there was no analyst reviewing the alerts they produced, and no schedule existed to review the collected logs.
The organization opted for Kaspersky’s Compromise Assessment service. Historical security logs were collected and investigated as part of the assessment procedures. The goal was simple: to determine what had really been going on in the network over the previous few months.
Log analysis revealed clear evidence of malicious activity. Activities related to Impacket behavior were discovered that led to the deployment of Cobalt Strike and Mimikatz on several critical servers, including the domain controllers. These activities were three months old at the time of detection, and the enterprise was unaware of them because there was no effective 24/7 monitoring in place.
Impacket is a collection of Python scripts for network protocols and low-level network packet manipulation. Attackers can abuse it to move laterally into the network. The following are examples of its artifacts detected in the network:
The attacker used Impacket to execute a PowerShell command that downloaded an executable from a command-and-control server. This server was found to be associated with Cobalt Strike. Cobalt Strike is a post-exploitation tool that provides capabilities for remote command execution and lateral movement within a compromised network. The execution was set up via a scheduled task that attempted to masquerade as a legitimate Google Chrome update task.
The timeline assessment confirmed the presence of a Mimikatz binary and a memory dump associated with the same incident on the compromised system, confirming that a credential theft operation had indeed taken place.
The organization was completely unaware of the breach. The activity had gone undetected for three months because the deployed controls were never monitored. Upon learning of the findings, a full-scale incident response was initiated to eradicate the footholds, rotate credentials, and harden the security of the environment.
Security controls are not self-sufficient. Deploying a firewall or an EDR solution does not automatically protect you. Without proper configuration, baseline tuning, and, most critically, continuous log monitoring and threat hunting, those controls become merely decorative. Always-on monitoring, either performed internally or delegated to an external managed security service, can turn weeks-old compromises into minutes-old alerts by correlating events, hunting for anomalous use of penetration testing or hacking tools, and escalating suspicious activity.
Incident response action statistics
An analysis of historical compromise assessment projects reveals a persistent discrepancy between the best practices described in incident response playbooks and the operational realities of executing them in unprepared, often legacy-affected environments. The figure below shows how frequently each response action was required during the initial response phase of a compromise assessment.
Incident response actions required after compromise assessment (download)
The distribution highlights three frequently observed patterns:
Forensic analysis accounts for the majority of cases, with around 59% requiring at least one forensic package collection and analysis.
Remote eradication, i.e., file or registry key removal, was reported in 39% of cases.
Plans evolve as the investigation proceeds; 39% of engagements required a mid-engagement plan update, reflecting the iterative nature of incident response.
Why forensic collection is the default entry point
Forensic package collection and analysis was the most frequent response action, occurring in 59% of cases. The prevalence of forensic package collection can be explained by two observable factors in CA engagements: (1) the targeted organization’s limited historical visibility and (2) the fact that a substantial proportion of incidents were older than 90 days at the start of the assessment. In many cases, native logs had already been rotated or purged, forcing investigators to rely on residual artifacts (e.g., MFT entries, registry hives, filesystem timestamps) to reconstruct timelines.
Our observations suggest that remote forensic package collection is effectively a prerequisite rather than an optional convenience. The graph below summarizes the reported ability to collect forensic packages, categorized by incident severity level. It highlights that, in a significant proportion of high-severity cases, the affected organization lacked this capability.
The organization’s ability to collect forensic data by incident severity (download)
Containment: The remove files/registry keys paradox
Response execution and eradication actions, such as file or registry key removal (reported in 39% of cases), were also common. However, they highlighted a notable gap in execution practices. While many organizations reported having EDR capabilities for remote removal, execution was often delegated to IT teams or MSPs via ticketing systems. This can introduce delays and reduce the precision of the removal process. Malware removal is a surgical process, particularly in multi-stage, fileless, or persistence-heavy scenarios. Capability alone is insufficient without expertise, sequencing, and planning, especially when artifacts may exist in shadow copies, backups, hidden paths, or downloader chains.
Communication failures: An additional operational overhead
A notable organizational finding emerged regarding communication. In 32% of projects, internal communication issues at the assessed organization materially impacted response execution. Below are the typical blockers:
Unclear action confirmation – system administrators could not quickly confirm whether a suspicious file was legitimate.
Delayed owner validation – ticket escalations stalled while waiting for system owners to respond.
Compromised communication channels – email accounts or ticketing portals may already be under the attacker’s control in the event of a suspected domain compromise.
Staff turnover – loss of knowledge about historical configuration baselines.
These findings suggest that regular tabletop exercises are required to test not only technical playbooks, but also human and communication workflows, as well as operational level agreements that govern and facilitate communication between different teams, and standard operating procedures for proper documentation.
The iterative nature of response plan updates
The need to update response plans based on new analytical input arose in 39% of cases, emphasizing the inherently iterative nature of incident response. Early-stage plans cannot realistically account for all variables. Examples of the most commonly observed causes for updating the response plan are listed below:
Reverse engineering results that reveal previously unknown command-and-control (C2) servers or behaviors.
Forensic discoveries, such as hidden scheduled tasks, shadow-copy artifacts, or dormant DLLs.
Traffic analysis outcomes that expose additional lateral movement paths.
Human constraints – unavailable system owners, changes in management processes, or supervisor approval.
Based on our experience, teams that treat the IR plan as a living document – incorporating each new artifact, reprioritizing actions, and reissuing the playbook before the next containment step – reduce the risk of missed eradication steps. Conversely, strict adherence to an initial, evidence-limited plan can increase the risk of overlooking persistent footholds.
Distinguishing real attacker artifacts from penetration testing leftovers
Finally, distinguishing attacker activity from penetration testing artifacts remained a recurring challenge (12% of cases). Compromise assessments frequently uncover remnants of legitimate testing tools, which can create uncertainty about whether a detected artifact originated from a malicious intrusion or a legitimate penetration test. Contributing factors:
Poorly documented penetration test report and artifact cleanup.
Overlapping toolsets (e.g., SharpHound) used by both red team operators and adversaries.
Running compromise assessments and active penetration testing projects simultaneously, which degrades analyst focus and increases false positive rates. Although correlating findings with penetration testing reports is essential, compromise assessments are human-driven investigative processes, and confusing analysts with overlapping “legitimate” attack signals leads to misinterpretation and weaker outcomes.
Incident response maturity and its effect on severity
Our data show a correlation between the presence of internal digital forensics or malware reverse engineering capabilities and the distribution of incident severity categories. Across the 2025 compromise assessment engagements, the distribution of low-, medium- and high-severity findings differed markedly between organizations that possessed these capabilities and those that did not. The data below illustrate this correlation and provide a basis for assessing the business value of expanding internal response skill sets.
Incident severity split for cases requiring digital forensics, based on an organization’s capabilities (download)
Organizations capable of analyzing digital forensic artifacts independently experienced half as many high-severity incidents and a higher proportion of low- and medium-severity cases.
Incident severity split for cases requiring malware analysis, based on an organization’s capabilities (download)
The presence of a dedicated reverse engineering resource correlates with a total absence of high-severity cases in our sample set; the majority of incidents were rated as medium severity, with a significant proportion of low-severity outcomes.
The analysis of this correlation indicates, with medium confidence, that the observed shifts are unlikely to be caused solely by sample size effects. Rather, they are more likely to reflect a genuine operational phenomenon: internal digital forensics and malware analysis capabilities contribute not only to SOC processes, but also to cyber-resilience in general.
Case study: In-memory LionTail infection on critical Windows servers
During a compromise assessment, a persistent in-memory threat was identified on several critical servers. The activity was attributed to the LionTail framework, a sophisticated set of custom loaders and memory-resident shellcode implants. LionTail takes advantage of undocumented Windows HTTP.sys driver behaviors to covertly deliver and retrieve payloads via inbound HTTP traffic, effectively blending malicious activity into legitimate network flows.
Several observed variants are attributed to the Scarred Manticore actor, which generates a unique implant per compromised host and performs data exfiltration while carefully masking command-and-control communications within normal-looking traffic.
Detection was achieved through static memory signatures discovered within the scrcons.exe process. Although scrcons.exe is a legitimate WMI host binary located under C:\Windows\System32\wbem, it is frequently abused to host injected payloads, making it an attractive target for stealthy in-memory operations.
The response plan comprised a number of actions, the most critical of which are highlighted below:
Collection of volatile memory dumps for in-depth analysis.
Acquisition of full forensic disk images from affected systems.
Detailed analysis of the collected artifacts and subsequent updates to the incident response plan.
Executing these actions proved challenging for the organization because of its limited digital forensics and reverse engineering capabilities. In incidents dominated by fileless memory-resident threats, these capabilities are not optional – they are essential. Without them, organizations risk losing critical evidence, misjudging the scope of the compromise, or failing to fully eradicate advanced implants that leave minimal traces on disk.
While our specialists were able to complete the investigation and contain the breach, the case revealed a readiness gap. It demonstrated the operational risk of depending on external assistance during high‑impact incidents and reinforced the necessity of in‑house forensic and reverse‑engineering maturity to achieve timely, confident and comprehensive incident handling.
Solving the root cause problems
Upon completion of a compromise assessment engagement, the focus shifts from incident response to a consulting phase. The final workshop focuses on preventing recurrence of incidents by identifying underlying deficiencies that allowed them to go unnoticed. The recommendations are actionable and tailored to the environment. For the purpose of this report, they have been grouped into a limited set of high-level categories.
Root-cause category
Share of incidents
Typical findings
Insufficient detection fidelity
60.7%
• No high-confidence alerts were generated by the EPP/EDR or related log sources.
• In 9.4% of cases, the product was mis-configured or out of date or malfunctioning.
Missing alert-driven monitoring
35.9%
• Alerts that could have indicated compromise were generated, but an incident was not declared.
• Signals with high uncertainty (e.g., heuristic web shell detections) required analyst validation.
Deficient vulnerability and configuration management
28.2%
• Evident misconfigurations (e.g., disabled audit logging, over-permissive service accounts).
• Known vulnerabilities left unpatched or unmitigated.
Lack of structured threat hunting processes
27.4%
• Low-fidelity alerts were never reexamined after initial dismissal.
• High-volume telemetry remained unchecked due to staffing constraints.
Inadequate security awareness programs
25.6%
• Credential leaks from personal devices of employees or contractors accounted for 27.2% of incidents where inadequate security awareness was identified.
• Social engineering attempts were successful because of insufficient user training.
Absence of documented policies/processes
23.9%
• No formal incident response playbooks, change management procedures or data handling guidelines were available.
Common observations on root causes
The detection health check was the most frequent corrective action. In more than half of the cases where alerts were missing, a simple verification of sensor health and rule relevance was recommended to fill the gap. Without such validation, immediate attribution of the failure to the product capability could not be made.
Human analysis is still essential for low-confidence alerts. Automated pipelines alone cannot compensate for rules prone to false positives (e.g., generic web shell heuristics). Embedding a manual triage step was recommended to reduce the dwell time for incidents.
Process hygiene (vulnerability management, threat hunting, security policies) accounts for a substantial proportion of the root causes. Even mature organizations exhibited gaps in routine activities that could be mitigated with disciplined workflows. The absence of documented policies/processes was the root cause of 23.9% of cases.
A modern example of a policy gap is the use of generative AI development tools that operate without clear data handling rules. During one project, we identified a macOS workstation that executed the Claude Code (Anthropic) command-line assistant as a VS Code extension. The tool automatically captured filesystem snapshots to enrich its language model prompts. These snapshots included full directory listings and absolute paths to several Excel workbooks containing internal confidential data:
ls -lh /Users/[REDACTED]/Documents/[REDACTED].xlsx /Users/[REDACTED]/Documents/[REDACTED].xlsx /Users/[REDACTED]/Documents/[REDACTED].xlsx .. [REDACTED]
The organization was advised to conduct awareness sessions for employees on the risk of exposing confidential internal data to generative AI tools, and to develop a policy governing the use of such tools with confidential information.
Lack of detections: Causes and impacts
Compromise assessment engagements repeatedly show that insufficient detection fidelity is a significant contributing factor to high-severity incidents. In cases where the target organization’s detection coverage was rated low, 52% of incidents were classified as high severity and 15% as low severity. This suggests a correlation: limited visibility appears to increase the proportion of incidents that evolve into high-severity compromises.
Incident severity distribution when detection coverage was insufficient (download)
A common assumption is that engaging a managed security service provider (MSSP) improves detection maturity. The data, however, show a more nuanced picture. Even when an MSSP is engaged, 26.5% of incidents related to low detection coverage remain unidentified, and roughly 50% of MSSP-supported projects have basic Windows audit gaps (e.g., missing event log collection or disabled audit policies).
These findings suggest that outsourcing alone does not guarantee effective detection; active governance and continuous validation are required. Detection should be treated as an evolving capability that requires continuous testing, measurement, and refinement, irrespective of whether it is managed internally or by a third party.
Statistics of missed incidents due to lack of detection capability with or without MSSP (download)
The analysis of root causes of missed detections reveals several recurring themes. In many environments, the technology is present but poorly operationalized. The main issues are:
Absence of endpoint protection platform (EPP) health check – nearly 50% of incidents escalated to high severity in engagements where the EPP health check was weak or absent. This reflects the classic “installed-but-not-enforced” risk, where agents are present but not tuned, updated, or validated.
Threat intelligence gaps – when there was no functional threat intelligence feed or platform, about half of the incidents reached high severity. Without curated indicators of compromise and contextual enrichment, analysts rely on generic alerts and may overlook known malicious behaviors.
The underlying issue is an alert-driven, set-and-forget mindset: organizations assume that deployed tools will automatically protect them, even though the tools are not continuously tuned, validated, or enriched with threat intelligence.
Incident severity breakdown where there was no EPP health check or threat intelligence
Missing control
High-severity
Medium-severity
Low-severity
EPP health check
48.3%
36.7%
15%
Threat intelligence feed
50%
40%
10%
Detection failures are rarely caused by a single missing control; they emerge from weak configuration, insufficient telemetry, and an absence of regular checks of controls and processes to ensure they are functional, especially in outsourced models. A hybrid monitoring approach that combines internal ownership with external MDR or MSSP support consistently proves to be the most resilient model when roles, expectations, and performance metrics are clearly defined. Detection must be treated as a living function, not a procurement outcome.
The following example illustrates the real-world consequences of control gaps by walking through a severe incident that persisted undetected for months simply because the organization lacked the necessary detection capabilities and security tools.
Case study: In-memory PurpleFox infection evades conventional endpoint protection
During a compromise assessment engagement, memory was scanned on the target hosts using the threat hunting rule set. Two hidden objects were identified:
PurpleFox rootkit code injected into legitimate svchost.exe processes on several critical servers.
PurpleFox drops specially crafted DLLs and forces svchost.exe to load them. From there, it installs a kernel-mode driver that gives the attacker persistent and stealthy execution capabilities, as well as the ability to pull additional payloads. This results in the loading of the XMRig miner.
The deployed EPP solution monitored file creation, registry modifications and network connections. However, its memory inspection module was disabled. Additionally, the signature set applied at the time of the assessment was not up to date. As a result, no alerts were generated for the injected DLLs or the miner’s shellcode. The compromise assessment team identified this detection gap during the memory analysis phase and documented the missing in-memory inspection capability in the final report.
The organization’s security operations were outsourced to an MSSP, which collected the logs and forwarded them to the SIEM solution. Because the logs never contained alerts for in-memory activity, PurpleFox activity was not identified.
Insufficient vulnerability management: A catalyst for high-severity compromises
In the 2025 compromise assessment engagements, more than half of the threats identified and linked to insufficient vulnerability management practices or missing patches were classified as high severity. The most frequently observed consequences were the deployment of web shells that enabled persistent remote code execution and the exploitation of misconfigured Active Directory instances.
Severity distribution of incidents due to improper vulnerability management (download)
The root causes of missing patches are multifaceted. They include inadequate asset inventory management (25% of projects) and the absence of formal vulnerability management processes (41% of projects). Moreover, 86% of organizations that claimed to have a vulnerability management program still exhibited exploited misconfigurations during compromise assessment engagements. These findings suggest that robust patch management, comprehensive asset inventory practices, and structured vulnerability management processes are critical for preventing high-severity incidents.
Case study: How overly permissive GPO-based software distribution goes wrong
During multiple compromise assessment engagements, a high-impact misconfiguration was consistently observed: a Group Policy Object (GPO) was used to point to an executable in a shared folder and run it on every workstation via a scheduled task. The access control list (ACL) on the share was set to “Everyone – Full Control”.
Given that any authenticated domain user can write to the share, an attacker who compromises a single low-privilege account can replace the legitimate binary with a malicious payload. The next scheduled task run propagates the payload automatically to all endpoints that receive the GPO. This provides:
Elevated execution context: the scheduled task typically runs under the SYSTEM or local administrator account.
Automatic lateral movement: the malicious binary propagates without requiring additional network exploitation.
Privilege escalation: a compromised low-privilege account can lead to domain administrator code execution.
Vulnerability management procedures that include systematic GPO and share permission audits would have flagged the writeable ACL as a high-severity finding, enabling remediation before exploitation. Remediation typically involves restricting the share permissions to “Authenticated Users” with read-only access and limiting modifications to certain privileged accounts. Incorporating these checks into the baseline security controls reduces the attack surface, demonstrating the tangible risk reduction achievable through disciplined vulnerability assessment and penetration testing (VAPT) practices.
Conclusion
In 2025, Kaspersky Compromise Assessment helped organizations reveal a persistent detection gap: 30.8% of all incidents and 52% of high-severity compromises had historical activity spanning over three months. Of all the incidents discovered, 20% were found manually, while 60% were missed by enterprises because of the absence of high-confidence alerts from existing tools. The oldest missed incident identified by the Kaspersky Compromise Assessment team in 2025 was four years old.
Post-incident checkups produced the highest percentage of high-severity findings, while regular proactive audits, compliance-driven audits, and audits performed before merging two networks tended to reveal issues earlier. This indicates that purely reactive investigations often miss hidden persistence. The top high-level recommendations for immediate improvement in 2025 for all projects were:
Run a comprehensive detection engine health check within 30 days of project closure, prioritizing telemetry integrity and rule relevance.
Introduce a Tier 1 alert validation team that reviews all low-confidence events on a defined schedule.
Ensure robust 24/7 monitoring augmented with threat hunting capabilities focused on baselining, low-fidelity alerts, and emerging adversary techniques.
Reevaluate the vulnerability management pipeline to ensure continuous patching and audit log activation across all critical assets.
Update security awareness curricula to address credential leakage from personal devices and reinforce secure BYOD practices.
Ensure periodic tabletop exercises are run to test technical playbooks and sharpen the team’s skills and communication workflows.
Establish operational-level agreements to govern and facilitate communication between different teams and standard operating procedures used for proper documentation.
Addressing the root cause categories systematically will reduce the likelihood of future blind spots and improve the overall security posture of the engaged organizations.
Interpol’s latest Asia and South Pacific cybercrime assessment shows how phishing, ransomware, DDoS attacks, infostealers, and AI-enabled scams are raising security risks across APAC.
Prinz Eugen ransomware prioritizes recently modified files and leaves no ransom note on disk, creating new pressure on backup windows, endpoint alerts, and incident response playbooks.
On April 29, 2026, a Linux kernel local privilege escalation vulnerability was publicly disclosed under the name "Copy Fail" (CVE-2026-31431). Cloudflare’s Security and Engineering teams began assessing the vulnerability as soon as it was disclosed. We reviewed the exploit technique, evaluated exposure across our infrastructure, and validated that our existing behavioral detections could identify the exploit pattern within minutes.
There was no impact to the Cloudflare environment, no customer data was at risk, and no services were disrupted at any point. Read on to learn how our preparedness paid off.
Background
Our Linux kernel release process
Cloudflare operates a global Linux server infrastructure at an immense scale, with datacenters located across 330 cities. We maintain a custom Linux kernel build based on the community's Long-Term Support (LTS) versions to manage updates effectively at this volume. At any given time, we may utilize multiple LTS versions from various series, such as 6.12 or 6.18, which benefit from extended update periods.
The community regularly merges and releases security and stability updates which trigger an automated job to generate a new internal kernel build approximately every week. These builds undergo testing in our staging data centers to ensure stability before a global rollout. Following a successful release, the Edge Reboot Release (ERR) pipeline manages a systematic update and reboot of the edge infrastructure on a four-week cycle. Our control plane infrastructure typically adopts the most recent kernel, with reboots scheduled according to specific workload requirements.
By the time a CVE becomes public knowledge, the necessary fix has typically been integrated into stable Linux LTS releases for several weeks. Our established procedures ensure that we have already deployed these patches.
At the time of the "Copy Fail" disclosure, the majority of our infrastructure was running the 6.12 LTS version, while a subset of machines had begun transitioning to the newer 6.18 LTS release.
About the Copy Fail vulnerability
It helps to understand the vulnerability before getting to the response story. A comprehensive write-up can be found in the original Xint Code disclosure post.
AF_ALG and the kernel crypto API
The Linux kernel's internal crypto API manages functions like kTLS and IPsec. Userspace programs access this via the AF_ALG socket family, allowing unprivileged processes to request encryption or decryption. The algif_aead module facilitates this for Authenticated Encryption with Associated Data (AEAD) ciphers.
An unprivileged program follows these steps:
Opens an AF_ALG socket and binds to an AEAD template.
Sets a key and accepts a request socket.
Submits input via sendmsg() or splice().
Executes the operation using recvmsg().
The splice() system call is critical here, as it moves data by passing page cache references.
Memory mechanics: page cache and in-place crypto
The page cache is a shared system cache for file contents. Modifying a page belonging to a setuid binary effectively edits that program for all users until the page is evicted.
The crypto API utilizes scatterlists, which are structures linking various memory pages. In 2017, algif_aead was optimized for in-place operations, chaining destination and reference pages together. This design lacked enforcement to prevent algorithms from writing past intended boundaries.
The vulnerability: out-of-bounds write
When the user executes recvmsg(), the authencesn wrapper in the kernel performs a 4-byte write past the legitimate output region:
By using splice(), an attacker can chain a target file's page cache pages to the scatterlist. The out-of-bounds write then taints the cached file, allowing an attacker to control which file is modified, the offset, and the specific 4 bytes written. This means the attacker can manipulate the following with this exploit:
File: Any readable file.
Offset: Tunable via assoclen and splice parameters.
Value: Controlled via AAD bytes 4-7 in sendmsg()
The exploit, step by step
The default exploit targets /usr/bin/su, a setuid-root binary present on essentially every distribution.
Cache Reference: Open /usr/bin/su as O_RDONLY and read() to populate the page cache. Use splice() on the file descriptor to pass these page cache references into the crypto scatterlist.
Setup: Create an AF_ALG socket, bind() to authencesn(hmac(sha256),cbc(aes)), set a key, and accept a request socket without needing privileges.
Write Construction: For each 4-byte shellcode chunk:
sendmsg() with AAD bytes 4–7 containing the shellcode.
splice() the binary into a pipe then the AF_ALG socket so assoclen + cryptlen targets the desired .text offset.
Trigger:recvmsg() initiates decryption. authencesn writes its scratch data to the target offset of /usr/bin/su in the page cache. Although the function returns -EBADMSG, the 4-byte write is now in the global page cache.
Execution: Running execve("/usr/bin/su") loads the tainted page cache. Since the binary is setuid-root, the injected shellcode executes with root privileges.
The upstream fix (commit a664bf3d603d) reverts the 2017 in-place optimization, removing the exploit.
How we responded
When the vulnerability was disclosed, many workstreams started in parallel:
Mapping the blast radius: Our security team worked with kernel engineers to determine which kernel versions were vulnerable and assess the potential exposure.
Validating coverage: Security reviewed the exploit technique and confirmed that our existing behavioral detections could identify the exploit pattern during authorized internal validation.
Proactive threat hunting: Security began searching for signs that the vulnerability had been exploited before it was publicly known, going back 48 hours in our fleet-wide logs.
Engineering a mitigation: Kernel engineers began building a runtime mitigation that would protect the fleet without breaking production services.
Continuing software updates: Our engineering teams worked on delivering an updated Linux kernel, which required carefully rebooting and rolling it out across our servers.
There was no customer impact at any point during this response.
Validating detection coverage
One of the first things our security team did was confirm that our existing endpoint detection would catch this exploit. Our servers run behavioral detection that continuously monitors process execution patterns. It doesn't rely on knowing about specific vulnerabilities; it watches for anomalous behavior across the fleet.
When our engineers validated the vulnerability internally as part of the response, the detection platform flagged it within minutes. The system linked the entire execution chain—starting at the script interpreter, moving through the kernel’s cryptographic subsystem, and ending at the privilege escalation binary—flagging it as malicious based on fleet-wide behavioral patterns.
This happened without a signature update, without a rule change, and without human intervention. Our behavioral detection coverage existed before we wrote any custom logic for this particular Copy File exploit.
The confirmation was important because it meant we had coverage before writing a vulnerability-specific rule.
Hunting for exploitation
While our engineering team moved to a more targeted mitigation, our security investigation had been running since disclosure. This is our standard procedure for any critical vulnerability.
Our security team operates on a simple principle for critical vulnerabilities: assume compromise until you can prove otherwise. The investigation started from the assumption that exploitation could have occurred before the vulnerability was public, and we worked systematically to either confirm or rule it out.
The exploit leaves a distinctive trace in kernel logs when it runs. We searched for that trace across our centralized logging infrastructure, covering 48 hours before the vulnerability was publicly disclosed. If someone had exploited this before the world knew about it, we would have seen it.
We pulled access logs for affected systems and reconstructed who connected, when, and what commands they ran. This gave us a complete forensic picture of interactive activity on potentially affected infrastructure.
We checked that system binaries had not been tampered with, validated cryptographic hashes against known-good package manifests, looked for persistence mechanisms, and audited network connections for anything unusual. Everything was clean.
Incident timeline and impact
This graph shows the progress of our mitigation program as it progressed through our infrastructure.
How did we mitigate it?
Because of the long timeframe involved in deploying a patched Linux kernel, we also pursued mitigating this exploit without a reboot.
Removing the module
The bug was in the algif_aead kernel module. Therefore, the simple fix was to just remove this module and disallow it from being reloaded.
This mitigation was therefore exactly what the Copy Fail write-up from the security researchers who identified it recommends.
Unfortunately removing the module would have impacted software that leverages the kernel crypto API. This meant that we had to figure out a more surgical mitigation.
Bpf-lsm
We’ve already developed and deployed such a tool for this exact scenario: bpf-lsm. Instead of removing the module, this tool leaves it loaded for legitimate users and uses a BPF Linux Security Module program to deny the socket_bind LSM hook for everyone else. This completely blocks the front door for any exploits.
A draft of the eBPF program was put together overnight. Team members picked it up the following morning, ran validations, and made it production-ready. The program is fairly straightforward. On every socket_bind call:
If the socket family is not AF_ALG, allow the call through unchanged.
If the family is AF_ALG, check the calling binary's path against an allow-list of the binaries we know to be legitimate users.
If the binary is on the allow-list, allow the bind. Otherwise, deny it.
To verify the mitigation on a given machine without exploiting it, the Copy Fail write-up gives a one-liner:
On a mitigated machine you get PermissionError: [Errno 1] Operation not permitted (or FileNotFoundError, depending on which mitigation is active) instead of a successful bind.
Rolling it out
Before enabling enforcement, we verified that our known internal service was the sole legitimate AF_ALG user to avoid accidental outages. We used prometheus-ebpf-exporter to hook the socket() syscall and track AF_ALG usage per binary across the fleet. This required no kernel changes and provided aggregate data from hundreds of thousands of servers within hours. Results confirmed the identified service was indeed the only legitimate user.
So the bpf-lsm rollout was deliberately staged in two steps:
Get visibility first. Push the ebpf-exporter config gated by salt. Confirm at the metric layer that the known service is effectively the only thing creating AF_ALG sockets.
Then enforce. Push the bpf-lsm program behind a separate enforcement gate.
In parallel, the upstream backport for our majority LTS line finally became available, and our internal automation built a patched kernel against it.
We started to test the patched kernel in our staging datacenters as soon as possible, then we resumed the longer reboot process in order to fully patch our fleet.
Remediation and follow-up steps
While we were prepared for this scenario, at Cloudflare we’re always learning and improving. Key areas we identified for improvement:
Better visibility into kernel-API dependencies. We will review kernel-subsystem usage across production services, so we can continue to quickly mitigate exploits without service disruption.
Better runtime mitigation. bpf-lsm is a valuable tool for mitigations, but we want to make this tool even better. This will include looking into faster deployments, better playbooks, and better logging and visibility of the tool.
Reduce attack surface of Linux Kernel. Review and audit our kernel configuration. Proactively identify unused modules or features so that we can remove them from our build entirely.
Conclusion
The "Copy Fail" vulnerability presented a unique challenge for us. Despite our practice of deploying Linux patch updates every two weeks, we remained vulnerable because a month-old mainline fix had yet to be backported to our primary kernel line. Despite that, we were still able to roll out patched kernels within hours of the backport's release. In the interim, bpf-lsm provided a surgical, no-reboot mitigation that secured our fleet. While our initial attempt to disable the problematic module failed, it did so safely within our internal staging environment rather than production, allowing us to identify this dependency.
By the end of the rollout, every machine in our fleet was protected by either a patched kernel or a bpf-lsm program denying the vulnerable code path to non-allow-listed binaries. There was no customer impact at any point during this incident, and we have committed to the follow-up work above to make our response faster and our visibility better the next time something like this lands. Responsible disclosure works, in-kernel visibility tooling pays off in moments exactly like this one, and bpf-lsm continues to be one of the most useful primitives we have for runtime kernel mitigation.
At Cloudflare, critical vulnerability response is a coordinated effort across Security, Engineering, Product, and many other teams. Special thanks to Ali Adnan, Ivan Babrou, Frederik Baetens, Curtis Bray, Piers Cornwell, Everton Didone Foscarini, Rob Dinh, Elle Dougherty, Kevin Flansburg, Matt Fleming, Kimberley Hall, Brandon Harris, Jerry Ho, Oxana Kharitonova, Marek Kroemeke, Fred Lawler, James Munson, Nafeez Nazer, Walead Parviz, Miguel Pato, Evan Pratten, Josh Seba, June Slater, Ryan Timken, Michael Wolf, Jianxin Zeng and everyone else who contributed to the investigation, mitigation, and remediation of Copy Fail. We'd also like to thank the Linux upstream maintainers and Copy Fail researchers whose work helped make a rapid response possible.
An FTC report says that Americans last year lost $2.1 billion in social media scams, such as shopping and investment schemes. Social media site have become the place where most of these scams start, and more than half of that money was stolen in scams began on Facebook, WhatsApp, and Instagram.
China-sponsored threat groups like Salt Typhoon and Flax Typhoon are increasingly relying on multiple massive botnets comprising edge and IoT devices to run their cyber espionage and network intrusion campaigns, CISA and other security agencies say. The use of such "covert networks" makes it more difficult to detect and mitigate their campaigns.
A group of unauthorized users reportedly has gained access to Anthropic’s controversial Claude Mythos Preview AI frontier model despite the AI vendor’s efforts to keep it out of public hands by limiting the organizations that can use it. Bloomberg reported that the unnamed group had tried multiple ways to gain access to the AI model..
Cisco has released security updates to fix multiple vulnerabilities in its Identity Services Engine and Webex Services, warning that successful exploitation could lead to remote code execution, root-level access, and user impersonation. The Cisco ISE vulnerabilities affect widely used enterprise authentication and collaboration systems, making patching a priority for organizations.
The Cisco ISE vulnerabilities and the Webex Services flaw have not been observed in active exploitation so far. However, the company has urged customers to update affected systems immediately to reduce risk exposure.
Critical Cisco ISE Vulnerabilities Enable Remote Code Execution
The most severe issues impact Cisco Identity Services Engine (ISE) and its Passive Identity Connector (ISE-PIC). These Cisco ISE vulnerabilities stem from insufficient validation of user-supplied input, a flaw that allows attackers to send specially crafted HTTP requests to targeted systems.
Among them, CVE-2026-20147 carries a CVSS score of 9.9 and allows an authenticated attacker with administrative credentials to execute arbitrary commands on the underlying operating system. According to Cisco, this could enable attackers to gain user-level access and then escalate privileges to root.
Two additional vulnerabilities, CVE-2026-20180 and CVE-2026-20186, also rated 9.9, allow attackers with read-only administrative access to execute arbitrary commands. These Cisco ISE vulnerabilities highlight how even limited privileges can be leveraged for deeper system compromise.
Cisco noted that exploitation in single-node deployments could disrupt services entirely, potentially leading to a denial-of-service condition where new endpoints cannot authenticate to the network.
Webex Services Flaw Risks User Impersonation
Alongside the Cisco ISE vulnerabilities, a critical issue has been identified in Cisco Webex Services. Tracked as CVE-2026-20184 with a CVSS score of 9.8, the flaw affects single sign-on integration with Control Hub.
This vulnerability is caused by improper certificate validation and could allow an unauthenticated remote attacker to impersonate any user within the service. Successful exploitation could result in unauthorized access to legitimate Webex accounts, raising concerns for enterprises relying on the platform for communication and collaboration.
Affected Versions and Exposure
The Cisco ISE vulnerabilities impact multiple versions of the platform. All Cisco ISE versions 3.5 and earlier are affected by CVE-2026-20147, while versions 3.4 and earlier are vulnerable to CVE-2026-20180 and CVE-2026-20186. Cisco ISE-PIC systems are also impacted regardless of configuration.
For Webex Services, the vulnerability affects deployments using SSO integration with Control Hub.
Cisco emphasized that the vulnerabilities are independent of each other, meaning exploitation of one does not require another. Some versions may be affected by specific flaws while not impacted by others.
No Workarounds Available, Patching is Essential
Cisco has confirmed that there are no workarounds to mitigate these vulnerabilities. Organizations must apply the available software updates to fully address the risks.
Fixed releases have been issued across supported versions. For example, patches include ISE 3.1 Patch 11, 3.2 Patch 10, 3.3 Patch 11, 3.4 Patch 6, and 3.5 Patch 3. Systems running versions earlier than 3.1 are advised to migrate to a supported release.
Security teams are also advised to review system configurations and ensure that upgrade prerequisites such as hardware compatibility and memory requirements are met before deployment.
No Active Exploitation Reported But Risk Remains High
The Cisco Product Security Incident Response Team has stated that it is not aware of any public exploitation or malicious use of these vulnerabilities at the time of disclosure. The issues were reported by Jonathan Lein of TrendAI Research.
Despite the lack of active attacks, the severity of the Cisco ISE vulnerabilities and the Webex flaw places them in a high-risk category. Vulnerabilities that allow remote code execution or user impersonation are often targeted quickly once technical details become public.
Security Implications for Enterprises
The Cisco ISE vulnerabilities are particularly significant because ISE plays a central role in network access control, authentication, and policy enforcement. A compromise could provide attackers with deep visibility and control over enterprise networks.
Similarly, the Webex vulnerability introduces risks to identity and access management, especially in environments that rely on SSO for centralized authentication.
Organizations using affected products are advised to prioritize patching, restrict administrative access where possible, and monitor systems for suspicious activity.
Cisco has made detailed advisories and upgrade guidance available through its security portal, and customers are encouraged to follow official recommendations to secure their environments.
NIST said it overwhelmed by the surge in the number of CVEs submissions in recent years, so it is paring back the analysis work it does on the dangerous security flaws. Security experts say the number of new vulnerabilities detected will only grow during the AI era and that the private sector will need to pick up the slack left by NIST's decision.
The fallout from the Axios npm supply chain attack continues to widen, with OpenAI issuing a detailed response outlining its exposure and remediation steps.
The Axios npm supply chain attack, reported by The Cyber Express on April 1, has since been linked to North Korea’s Lazarus Group, significantly expanding the scope and impact of the incident. Attribution was confirmed by Google Threat Intelligence Group, which identified the activity under UNC1069, a financially motivated group active since at least 2018.
OpenAI Confirms Limited Exposure to Axios npm Supply Chain Attack
In its official statement, OpenAI said, “We recently identified a security issue involving a third-party developer tool, Axios, that was part of a widely reported, broader industry incident.” The company clarified that while it was affected by the broader Axios npm supply chain attack, there is no evidence of compromise to user data or internal systems.
“We found no evidence that OpenAI user data was accessed, that our systems or intellectual property was compromised, or that our software was altered,” the statement added.
The exposure occurred on March 31, 2026, when a GitHub Actions workflow used in OpenAI’s macOS app-signing process executed a malicious version of Axios (v1.14.1). This workflow had access to sensitive code-signing certificates used for validating OpenAI applications like ChatGPT Desktop, Codex, Codex CLI, and Atlas.
Certificate Rotation and macOS App Updates
As a direct response to the Axios npm supply chain attack, OpenAI has initiated a full rotation of its macOS code-signing certificates. While internal analysis suggests the certificate was likely not exfiltrated, the company is treating it as potentially compromised.
To mitigate any residual risk, OpenAI is requiring users to update their macOS applications. Older versions of affected apps will lose support and functionality after May 8, 2026. Updated versions will carry new certificates to ensure authenticity.
This move is designed to prevent threat actors from distributing malicious software disguised as legitimate OpenAI applications, a known risk in supply chain attacks involving code-signing materials.
Investigation and Security Measures
OpenAI engaged a third-party digital forensics and incident response firm to investigate the impact of the Axios npm supply chain attack. The company also coordinated with Apple to block any new notarization attempts using the old certificate.
Additional steps taken include:
Publishing new builds of all affected macOS applications
Reviewing all past software notarizations for anomalies
Ensuring no unauthorized modifications were made to distributed software
The company confirmed that no malicious applications signed with its certificate have been identified so far.
Root Cause: GitHub Workflow Misconfiguration
The root cause of OpenAI’s exposure to the Axios npm supply chain attack was traced to a misconfiguration in its GitHub Actions workflow. Specifically, the workflow relied on a floating tag instead of a fixed commit hash and lacked a minimum release age for dependencies, both of which increased the risk of pulling compromised packages.
This highlights a broader industry issue where development pipelines remain vulnerable to upstream compromises, especially in open-source ecosystems.
No Impact on User Data or Other Platforms
OpenAI emphasized that the incident is limited strictly to macOS applications. There is no impact on iOS, Android, Windows, Linux, or web-based services.
The company also reassured users:
OpenAI will fully revoke the old certificate on May 8, 2026, after a 30-day transition window. This approach is intended to minimize disruption while ensuring users have adequate time to update their applications.
The company noted that any software signed with the old certificate will be blocked by macOS security protections after revocation, further reducing the risk of misuse.
Growing Impact of Axios npm Supply Chain Attack
The Axios npm supply chain attack highlight the escalating risks tied to third-party software dependencies. With attribution pointing to a state-sponsored group, the incident reflects how supply chain attacks are increasingly being leveraged for financial and strategic objectives.
As organizations continue to rely heavily on open-source libraries, the incident serves as a reminder of the need for stricter dependency management, secure development practices, and continuous monitoring of software pipelines.
Stop running your SOC like it’s 2012. Learn why modern detection engineering requires shifting away from legacy SIEM architectures toward a product-centric strategy that prioritizes data quality, contextual enrichment, and AI-native workflows over raw log volume.
In 2026, hybrid warfare is no longer a theoretical construct discussed in policy circles; it is shaping geopolitical conflict in real time. The convergence of cyber warfare and kinetic attacks has transformed how nations project power, blending missiles, malware, and misinformation into unified campaigns. What distinguishes modern hybrid warfare from earlier conflicts is not just the presence of digital operations, but their synchronization with physical strikes to produce layered, systemic disruption.
Nowhere is this more evident than in the Middle East, where escalating tensions have turned the region into a proving ground for cyber-physical warfare. Governments, energy systems, financial networks, and communication infrastructures are being targeted simultaneously, exposing vulnerabilities that extend far beyond national borders. The result is a battlespace where the frontlines are both physical and invisible, and where disruption can ripple globally within hours.
From Conflict to Convergence: The Rise of Cyber Physical Warfare
The turning point came on February 28, 2026, when coordinated military and cyber campaigns marked a new phase in hybrid war strategy. Joint operations combined airstrikes with cyberattacks, information warfare, and psychological operations, targeting nuclear facilities, military assets, and digital infrastructure in parallel. Internet connectivity in targeted regions dropped to as low as 1–4% of normal levels during the initial assault, demonstrating the effectiveness of integrated cyber warfare and kinetic attacks.
These operations were not designed for immediate destruction alone. Instead, they aimed to disorient command structures, disrupt civilian communication, and weaken public trust. Digital interference extended to media channels and widely used mobile applications, some of which were compromised to spread false information and induce panic.
The response was equally multifaceted. Within 72 hours, missile and drone strikes were accompanied by a surge in cyber activity, including spear-phishing campaigns, ransomware-style attacks, and coordinated data exfiltration efforts targeting energy grids, airports, and financial institutions.
Hacktivists as Force Multipliers in Modern Hybrid Warfare
One of the defining characteristics of modern hybrid warfare is the role of non-state actors. More than 70 hacktivist groups became active participants in the 2026 conflict, blurring the lines between state-sponsored operations and independent cyber activism. These groups executed distributed denial-of-service (DDoS) attacks, website defacements, and credential harvesting campaigns across multiple countries.
Their involvement amplifies the scale and unpredictability of cyber warfare and kinetic attacks. While some groups operate with ideological motivations, others appear loosely aligned with state objectives, acting as force multipliers without formal attribution. This ambiguity complicates response strategies and increases the risk of escalation.
Cyber campaigns emerged during this period, including fake missile alert applications designed to harvest sensitive user data such as contacts, messages, and device identifiers. These tools demonstrated a level of technical refinement typically associated with advanced persistent threat (APT) groups.
Iranian Cyber Capabilities and Strategic Depth
Despite early disruptions to its infrastructure, Iran maintained a good cyber posture throughout the conflict. Established threat groups continued to conduct espionage, infrastructure attacks, and credential theft operations targeting sectors such as energy, aviation, and telecommunications.
Parallel to these efforts, Iran-aligned hacktivist groups escalated disruptive campaigns, including industrial control system intrusions and data leaks. Some reports suggest coordination with Russia-linked actors.
A notable example is the emergence of hybrid threat actors employing destructive malware. Tools designed to overwrite system data, disable operating systems, and erase critical infrastructure highlight a shift toward more aggressive cyber physical warfare tactics. These operations are often executed in stages: initial access through phishing or exposed services, lateral movement using legitimate system tools, and eventual payload deployment designed for maximum disruption.
Infrastructure Disruption and Global Spillover Effects
The consequences of hybrid warfare are not confined to the immediate conflict zone. Early incidents in 2026 disrupted fuel distribution in Jordan and interfered with navigation systems, affecting over 1,100 vessels near the Strait of Hormuz. These disruptions pose significant risks to global oil and gas supply chains, illustrating how localized cyber warfare and kinetic attacks can have worldwide economic implications.
Countries like India are experiencing indirect exposure due to interconnected digital ecosystems. Supply chain dependencies, shared technologies, and cloud-based services create pathways for cyber threats to propagate across borders. Vulnerabilities in widely used platforms, including VPNs and enterprise communication systems, are actively exploited.
Attackers are also leveraging AI-driven techniques to enhance their effectiveness. Phishing campaigns now use highly personalized messaging, while automated reconnaissance tools map organizational structures to identify high-value targets. These capabilities reduce the time required to execute complex attacks and increase their success rates.
Cybercrime Exploitation in a Hybrid War Environment
Geopolitical instability has created fertile ground for cybercriminal activity. More than 8,000 domains linked to the 2026 conflict have been registered, many serving as platforms for scams, malware distribution, and misinformation campaigns.
Examples include fake donation websites, fraudulent e-commerce platforms, and cryptocurrency schemes designed to exploit public sentiment. Conflict-themed malware, often disguised as alert systems or news updates, has been used to deploy backdoors and establish persistent access to compromised systems.
This convergence of cybercrime and state-aligned activity reflects a broader trend: the industrialization of cyber threats. Ransomware-as-a-service platforms now provide end-to-end attack capabilities, lowering the barrier to entry for less experienced actors. With subscription costs as low as $500 per month, cyberattacks are becoming accessible.
India’s Evolving Role in the Hybrid Warfare Landscape
India’s cybersecurity environment in 2026 reflects many of the same dynamics observed in the Middle East. State-sponsored actors are focusing on long-term access and intelligence gathering, targeting government networks, defense systems, and critical industries. These operations often remain undetected for extended periods, leveraging advanced persistent techniques to maintain access.
At the same time, hacktivist groups in India are becoming more organized and technically capable. Their activities now include coordinated data leaks, disruption campaigns, and the use of advanced tools traditionally associated with nation-state actors.
Supply chain attacks are a growing concern, particularly in sectors undergoing rapid digital transformation. Healthcare, manufacturing, and financial services are vulnerable due to their reliance on interconnected systems. These vulnerabilities highlight the importance of continuous monitoring, vendor risk management, and layered security architectures.
Intelligence-Driven Defense in the Age of Hybrid War Strategy
As hybrid warfare evolves, traditional reactive security models are proving insufficient. Organizations are shifting toward intelligence-driven approaches that integrate tactical, operational, strategic, and technical insights.
This shift is critical in a landscape where attackers exploit legitimate platforms, use “living off the land” techniques, and maintain persistence for extended periods. Behavioral analytics, anomaly detection, and contextual authentication are becoming essential tools for identifying threats that bypass conventional defenses.
Equally important is the adoption of proactive measures such as multi-factor authentication, network segmentation, and robust incident response frameworks. Information sharing between organizations and governments is also emerging as a key component of resilience in the face of coordinated cyber warfare and kinetic attacks.
Conclusion
Hybrid warfare in 2026 is an operational reality. Cyber warfare and kinetic attacks now work in tandem, creating rapid, high-impact disruptions across both digital and physical systems. This is the core of modern hybrid warfare: fast, coordinated, and difficult to contain.
Defending against this requires a shift to intelligence-led security. In a landscape shaped by cyber physical warfare, organizations need real-time visibility, faster response, and the ability to anticipate threats, not just react to them. Cyble enables this shift with its AI-native platform, Cyble Blaze AI, designed to predict and stop threats before they escalate.
Strengthen your hybrid war strategy, explore Cyble’s threat intelligence capabilities or schedule a demo to see proactive security in action.
Entrar
![[Webinar] Tales from the Frontlines: An exclusive briefing on Q2 incidents](https://storage.ghost.io/c/af/a0/afa04ee3-414f-4481-8d23-7e7c146f192e/content/images/2026/08/2-1-no-copy.jpg)
Source: Kenya’s Ministry of Information, Communications and the Digital Economy[/caption]
