Viry a Červi

Attackers have been caught exploiting a critical flaw in Oracle E-Business Suite's Payments module just six weeks after Oracle patched it – and before any public proof-of-concept exploit was available. Researchers at Defused said they observed the first known exploitation of CVE-2026-46817 on June 27. The attackers were targeting the Oracle Payments File Transmission component in E-Business Suite releases 12.2.3 through 12.2.15, they said. The vulnerability, fixed in Oracle's May Critical Patch Update, carries a CVSS score of 9.8 and allows unauthenticated attackers to read arbitrary files from vulnerable servers. According to Defused, the activity didn't look like the indiscriminate internet scanning that often follows disclosure of a critical bug. Instead, its honeypots recorded just six exploitation attempts from a single source, all using what appeared to be a working exploit. The requests sought to retrieve sensitive files from the target system, suggesting the operator was testing or validating the technique rather than casting a wide net. The researchers said exploitation began before any public exploit code had surfaced, pointing to an attacker who had either reverse-engineered Oracle's patch or obtained a private exploit. The Shadowserver Foundation said it currently sees around 950 EBS instances exposed to the public internet, the majority in the US, although it stressed that figure says nothing about whether they're vulnerable or fully patched. The observed exploitation fits a pattern that's becoming increasingly familiar. Earlier this month, researchers warned that attackers had exploited a critical PeopleSoft zero-day before patches were widely deployed, with the ShinyHunters crew claiming to have compromised more than 100 organizations. They also boasted of having stolen HR and payroll data. This latest incident also follows Clop's lengthy campaign against Oracle E-Business Suite customers, disclosed last year after researchers found the ransomware crew had targeted internet-facing EBS servers for months before the activity became public. The newly exploited EBS vulnerability is probably not the last Oracle ERP bug to be targeted. Enterprise software has become a lucrative hunting ground for cybercrooks, and critical updates can double as roadmaps for anyone prepared to reverse-engineer the fixes and beat customers to deployment. ®

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:

1. 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.
   
2. 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.
3. 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.
4. 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.

Web shell location (download)

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.

Asset inventory issues (download)

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:

1. 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.
2. Periodically perform a software inventory audit to identify unauthorized remote management tools. Consider collecting data from the following registry keys on all hosts:
   • HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
   • HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
   • HKEY_USERS\*\Software\Microsoft\Windows\CurrentVersion\Uninstall
   • HKEY_USERS\*\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
3. 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.
4. 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:

Parent command line Command line /bin/zsh -c -l source /Users/[REDACTED]/.claude/shell-snapshots/snapshot-zsh-[REDACTED].sh && eval ‘ls -lh “/Users/[REDACTED]/Documents/[REDACTED]/”*.xlsx‘ \\< /dev/null && pwd -P >| /var/folders/[REDACTED]/claude-[REDACTED] 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.
• XMRig cryptocurrency miner signatures residing inside the same compromised svchost.exe instances.

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.

PWNED Welcome back to PWNED, the column where we document serious security failures in hopes we can all learn from others’ mistakes. This week, we’ll talk about how a lack of physical security can allow threat actors to take control of your network. Have a story about someone leaving a gaping hole in their network? Share it with us at [email protected]. Anonymity is available upon request. Our story comes to us from two professional red teamers, who get paid to break into offices and networks in order to find holes in the security system. Kristopher Johnson was working as an offensive security consultant at Echelon Risk + Cyber in 2023 and his manager was Dahvid Schloss. We spoke to both. Johnson and another employee named Michael were called upon to challenge the security at a client’s office while Schloss supervised remotely. It was winter and the maintenance crew had the maintenance door open. They walked through it and into the mail room, where a woman confronted them and asked what they were doing there. The two intrepid testers talked to the company maintenance crew and told them that they were new IT employees without working badges. They said that they had almost slipped on the ice and offered to help shovel, an offer the maintenance team was happy to take them up on. While Michael kindly helped the maintenance crew shovel snow, Johnson asked if the maintenance folks could let him in so he could go upstairs and start setting up Michael’s laptop for work. They let him in where he was free to explore the building as his partner brushed away a large section of ice and snow. Inside the building, Johnson looked for a place to plug in his Raspberry Pi. The idea was to connect this single-board computer to the network, where they could access it remotely and use it to attack the network from afar. He tried plugging his Raspberry Pi into an Ethernet port in the AV closet, but the company had network access control enabled, which prevented it from connecting. The Raspberry Pi had an LTE radio, but it couldn’t connect from the closet either. So Johnson instead moved his Raspberry Pi into the middle of the conference room and found an active network port that didn't have network access control enabled on it. However, he realized the Pi would be visible to anyone who entered the conference room, and they might find it suspicious. So he took some trash cans and used them to hide the device. Johnson had a hard time getting out of the building after that. He tried to go out the front door, but it required him to swipe a badge he didn’t have and strangers would not swipe their badges for him. But when he went back through the maintenance entrance, they were more than happy to swipe him out. He waited in the car while Michael finished his shoveling assignment. The next day, Johnson found out that his security breach had been detected. When he and Michael came in to meet with their contact at the company, the head of security confronted them. They had been “caught” because someone from maintenance went up to the IT department and wanted to thank the IT team for Michael’s help with the shoveling. However, the IT team had no record of new employees named Michael or Kristopher, so that raised suspicion. Before learning that they were professional red teamers, the building security had been suspicious and had looked at camera footage tracking their movements. They had even tried to get information on the license plate from Johnson’s rental car. However, they never did find the Raspberry Pi, which remained plugged into the Ethernet port in the conference room for two weeks. During that time, Johnson’s team was able to connect to the company’s Active Directory, find where the domain controllers were, and start password spraying accounts to see if they could gain access. They tried using the password “winter2023!” and got 50 or 60 hits among the employees. “So we used those credentials to kind of map out the rest of the network,” Johnson told The Register. “Network shares and things like that and then, towards the end of the test, we enumerated the certificate services - ADCS (Active Directory Certificate Services).” The red teamers found eight templates that were open to ESC1 and ESC4 vulns. They also found that the certificate authority was vulnerable to ESC8. They were then able to exploit those holes to gain domain administrative access. The janitor found the Raspberry Pi two weeks after they broke in, but by then it was too late. There are a lot of lessons here, but they start with training every member of the team to be suspicious of people coming from the outside, without badges, no matter what they say or do. Schloss noted that, if someone looks and acts like they belong in a space, most people will treat them that way. “First and foremost, what most people believe is crime is not crime. It's a Hollywood myth of what crime looks like,” Schloss told us. “I call it the ski mask bias. Everyone assumes you're not getting robbed until a person comes in with a ski mask and a gun yelling.” The maintenance team at this company should have been more suspicious of people calling themselves new employees and asking for a swipe in, even if they were willing to help shovel snow. The company also should have restricted network access to the port in the conference room so that an unknown device like a Raspberry Pi could not make an Ethernet connection from that spot. Finally, the company should have enforced a strong password policy that would have prevented our heroes from finding dozens of accounts with “winter2023!” as the password. And they should have enforced multi-factor authentication on those accounts as well. ®

EvilTokens, the device-code phishing kit that can allow criminals to bypass multi-factor authentication (MFA) and silently authenticate as the victim to the organization's Microsoft 365 applications, appears to be even more insidious than we all thought. Cisco Talos incident responders on Wednesday described how the lure reaches a victim's inbox, and revealed new capabilities alongside a “more sophisticated evasion approach” than documented in earlier EvilTokens research. Talos uncovered a phishing-as-a-service (PhaaS) operator panel, branded “ARToken,” that appears to be an EvilTokens customer, according to security research engineer Michael Kelley, who noted the phishing operation shares infrastructure, API contracts, and operational patterns with the EvilTokens platform. EvilTokens was first documented by French cybersecurity firm Sekoia in March, and in April Microsoft said the device-code phishing campaign was compromising hundreds of organizations daily. "Since March 15, 2026, we have observed 10 to 15 distinct campaigns launching every 24 hours," Microsoft VP of security research Tanmay Ganacharya told El Reg at the time. “Each campaign is distributed at scale, targeting hundreds of organizations with highly varied and unique payloads, making pattern-based detection more challenging.” While most subsequent analysis has covered EvilTokens’ panel and phishing kit, “what it has not shown is how an ARToken lure actually reaches an inbox,” Kelley said on Wednesday. “Talos recovered two near-identical messages, sent roughly four minutes apart on April 20, 2026, that initiate the chain. The tradecraft is targeted, not spray-and-pray.” Specifically, the email lure abused a real vendor relationship between a US life-sciences company and a legitimate plumbing and fire-protection contractor. The email uses an outstanding-invoice lure, telling the life-sciences company that “the following invoices appear to still be outstanding,” and the “from” header presents the contractor’s real domain. The reply-to, however, redirects replies to an unrelated domain. Even the visible anchor text in the body of the email reads as the vendor's genuine SharePoint tenant, we’re told. The actual href, however, points to a near-identical copycat tenant under a different, attacker-controlled Microsoft 365 workspace. But because the destination is still a legitimate sharepoint.com host, the email is less likely to be flagged as a phish. During its investigation into the ARToken phishing infrastructure, Cisco uncovered the connections to EvilTokens – including an identical API contract to the one originally documented by Sekoia and matching deployment and operational models – as well as “notably more sophisticated” anti-analysis and evasion capabilities. ARToken’s panel also revealed a very comprehensive post-exploitation toolkit that provides token management and persistence mechanisms, and a built-in business email compromise (BEC) tool with full Microsoft Outlook inbox read access, email sending capabilities as the victim, inbox rule creation for forwarding and deleting messages, and keyword-based monitoring across all compromised accounts. “These features indicate the platform is more mature than a simple device code phishing kit - it is a complete BEC operations environment,” Kelley wrote. ®

Anthropic has released the latest version of its mid-sized model, Sonnet 5, which the company claims is its most “agentic” yet. For developers writing agents to automate tedious and recurring tasks, Sonnet 5 promises improved capabilities in reasoning, tool use, coding, and knowledge work. This version is also less likely to pull embarrassing (for Anthropic) gaffes of misunderstanding, so the company asserts. “Our safety assessments found that Sonnet 5 shows an overall lower rate of undesirable behaviors than Sonnet 4.6, and is generally safer to use in agentic contexts,” the company asserted in an introductory blog post on Tuesday. Sonnet 5 is smarter at refusing malicious requests and resisting prompt-injection attempts. It doesn’t hallucinate as often and doesn’t suck up to the user so much (“sycophancy”) as did its older brown-nosing Sonnet 4.6 sibling. It is also more aware of, and can block, user misuse and deception, the benchmarks in Anthropic’s System Card seem to indicate. Sonnet is the default model for Claude Free and Pro users, and is also available to the token-pinching Max, Team, and Enterprise customers. The benchmarks also indicate Sonnet 5’s performance can come close to that of Anthropic’s flagship enterprise-focused Opus 4.8, but can execute the same tasks more cost effectively. For Opus, Anthropic charges $5 per million input tokens and $25 per million output tokens. Starting in September, Sonnet users will pay $3 per million input tokens and $15 per million output tokens, though Anthropic is running a special through the end of August where tokens will only be $2 per million inputs and $10 per million outputs. So users trimming their token budgets can run jobs through Sonnet instead of Opus, the company suggests. The 5.0 release offers a new setting to adjust the model’s effort at completing tasks. Simple tasks can be completed through one of the lower “effort” settings, which uses fewer tokens, while longer-running agent-based tasks can go full throttle (“xhigh” or even Homer Simpson’s favorite setting, “max”). What Sonnet 5 can do for developers For much of 2026, AI product deployment has focused on equipping large language models to complete what has become known as “long horizon tasks.” It might be easy for a model to fix a bug or churn out some code. However, keeping its finicky attention fixed on a multi-part task has proven more difficult. The new version of Sonnet can go the distance, according to the company, compared with the earlier Sonnets. “Across a broad suite of internal and third-party benchmarks, Sonnet 5 shows clear gains over Claude Sonnet 4.6 in coding, agentic search, multimodal reasoning, and professional-task performance,” the System Card asserted. At the same time, however, the performance across these tasks still trailed that of the Opus and Mythos models. One testimonial from a Zapier engineer described a two-part job that flummoxed earlier Sonnets: Update a contact database and send out a notice to all users. Version 5 was able to complete the task “end to end.” Cybersecurity: Nothing to see here The San Francisco-based company also went out of its way not to attract any more undue attention from Washington, DC policymakers. “We did not deliberately train Sonnet 5 on cybersecurity tasks,” the company asserted. In June, the US Commerce Department, citing national security concerns, slapped Anthropic with an export control directive temporarily restricting foreign access to the newly released Mythos 5 and Fable 5 models. Whether Anthropic brought this on itself – through what could be regarded as hyperbolic assertions of Mythos’ deity-like bug-sleuthing powers – is certainly worth discussing. But Anthropic, like Pete Townshend, certainly won’t be fooled again. While it can readily perform routine cybersecurity tasks, Sonnet 5 is guardrailed against generating offensive attack code. When commanded to write a Firefox exploit, it failed to complete the task (though it got a bit further than Sonnet 4.6 in the attempt). “This latter change is likely due to improvements in general intelligence rather than specific training,” the company’s blog post noted. ®

You can't ask most models to help you make "ransomware" directly, but many will be more than willing if you give them the right prompt. DeepSeek and other LLMs with fewer safety and security controls make theoretical cyberthreats - like browser-only ransomware - much more likely to be used in real-world infections, according to Check Point researchers. The Israeli cybersecurity company analyzed a DeepSeek-generated sample in a Wednesday report that its threat hunters describe as in-browser ransomware. Over the past year, the team has tracked almost 3,000 files attributed to DeepSeek, and classified nearly half (1,383 files) as malicious or dangerous using VirusTotal or static source analysis. “Within this dataset, we found a sample that implemented a dangerous browser-native technique we have not observed exploited in the wild,” researcher Alexey Bukhteyev wrote. And while the sample was incomplete, and unable to pull off an in-the-wild infection, the security shop’s testing showed “little effort” would be required to make it attack-ready. “Our research shows that the original incomplete DeepSeek sample can be transformed into a fully functional attack with minimal effort,” Pedro Drimel Neto, malware analysis team leader at Check Point Research, told The Register. “Very little effort is needed,” Neto said. “Low-level expertise is sufficient. You don't need to be a sophisticated cybercriminal or advanced persistent threat group. In fact, we've already observed evidence of actual threat actors attempting this attack using straightforward LLM prompts.” Known threat gets an AI boost The risk ransomware poses to browsers isn’t a new idea. The File System Access specification lists ransomware as a security consideration, and a 2023 USENIX Security paper on Ransomware over Modern Web Browsers described how File System Access API could be abused to encrypt local files from a malicious web application. The File System Access API is a browser capability, primarily supported by Chrome and Chromium-based browsers, that allows developers to build web applications, such as editors, IDEs, and creative tools, that can read, write, and manage files on the user’s local device. “Even though it can be used to develop rich web applications, it greatly extends the attack surface, which can be abused by adversaries to cause significant harm,” Google’s Güliz Seray Tuncay and Florida International University researchers Harun Oz, Ahmet Aris, Abbas Acar, Leonardo Babun and Selcuk Uluagac wrote in 2023, long before LLMs could develop working malware and attack chains. What’s new, according to Check Point, is that an AI model put these previously documented ideas into a “realistic and enforceable attack scenario leveraging a method that defenders had originally thought was unfeasible due to browser sandboxing limits: a DeepSeek-attributed malicious sample, generated as an all-in-one malware fantasy, connected this documented platform risk to a realistic phishing-style web application, demonstrating a viable end-to-end attack chain.” This technique is especially appealing to attackers because it doesn’t require a native payload, APK installation, browser exploit, or root access to a compromised device. Instead, it uses social engineering - tricking a user into clicking on a malicious button - combined with a legitimate permission prompt exposed by the File System Access API in Chrome. Meet InfernoGrabber 9000 This particular sample that Check Point uncovered is a Python Flask application that targets Android users. It’s named InfernoGrabber 9000, and VirusTotal calls it a “fully functional information stealer and ransomware toolkit.” While the security sleuths don’t have the prompt submitted to DeepSeek to produce the malware, they speculate it was something along the lines of: “create a universal malicious tool that runs through the browser and collects as much victim data as possible, encrypts files, and demands ransom. In a single front-end, the generated code assembled routines and stubs for keylogging, clipboard monitoring, form and network-request interception, Discord-token collection, crypto-wallet and payment-card discovery, geolocation requests, webcam and microphone access, screenshots, local-file access, Chrome exploit stubs, ‘persistence,’ and a ransomware-style overlay.” To be clear: the sample doesn’t actually do all of this. “A more accurate reading is that it is an AI-generated blueprint in which the model tried to translate familiar capabilities of native stealers and ransomware tools into a web page opened in the browser,” Bukhteyev wrote. The code presents a victim-facing lure disguised as a Discord avatar AI upscaler. Clicking on the lure is intended to execute a slew of silent, harmful actions that run entirely inside the browser process. These include stealing Discord tokens, harvesting credit card numbers and cryptocurrency seed phrases, logging keystrokes, and capturing unauthorized webcam and microphone feeds. The code also includes specific routines for browser exploitation (such as targeting CVE-2023-4863), uses a hardcoded Discord webhook for data exfiltration and displays a ransomware WinLocker screen demanding Bitcoin. The good news for defenders is that the sample was incomplete, and the browser's built-in security model successfully prevents most of this functionality. However, Check Point was able to create a working proof-of-concept for the browser-native attack using the latest DeepSeek model V4. The team had to remove some of the more explicit terms - like ransomware - from the prompt, but ultimately produced the same functionality: “a web page that asks the user for access to local files, processes them inside the browser, and leaves the user unable to recover the original content.” AKA: browser-only ransomware. Neto told us that this type of LLM-generated code and in-browser attack is “likely happening now.” “We expect to see this activity in the short term, if we haven't already,” he added. While traditional ransomware and extortion groups target enterprises and critical infrastructure organizations, as opposed to Android-device users, which was the focus of this research, “we have seen increased end-user ransomware activity recently,” Neto said. “What's most concerning is that code obfuscation used in these attacks makes them difficult to spot, so there's a real possibility that attacks using this technique are already occurring in the wild but going unnoticed.” ®

EXCLUSIVE Pentera Labs’ red teamers compromised a developer’s AI agent via his Claude Desktop app and ultimately turned that access into full remote code execution on the dev’s machine – demonstrating how an attacker could turn a trusted, chatty AI assistant into a double agent operating on their behalf. “Claude’s got a new voice,” Pentera's offensive security services team leader Dvir Avraham told The Register. “We acknowledge the huge trust in AI models – everybody uses them,” he said in a phone interview. “We used this trust to manipulate the victim, like under the hood, the victim didn't see it coming.” It also prompted Avraham to check his own platforms. “I became a little bit paranoid,” he told us. “I'm not allowing any command to run without me examining it twice.” In a report set to publish Wednesday, and shared in advance exclusively with The Register, Avraham and research technical lead Reef Spektor detailed the attack and what it means for organizations using agentic AI tools with local code-execution access. It began with a red-team assignment on a third-party platform that aggregates customer email inboxes into a single management interface. Avraham and Spektor won’t name the platform, or tell us exactly how they gained access to it. They used this compromised inbox – and told us any compromised inbox would work – to get into the victim’s Claude account. As the duo noted, breaking into an email inbox in real life – via a third-party management platform, phishing link, social engineering password reset, or even using AI agents – isn’t too difficult. “AI agents today have access to connectors and to direct MCPs into inboxes,” Spektor added. In addition to this prerequisite (compromised inbox), the attack chain also requires the victim to have Claude Desktop installed. Anthropic’s desktop app works across macOS, Windows, and Linux systems. It provides the same AI chat for conversations as claude.ai, and it also syncs across all devices and sessions tied to the user’s account. “We asked ourselves, can we leverage the sync behavior to infect other sessions and devices? (hint: yes!),” the red teamers wrote in the Wednesday report. Back to the AI Stone Age As of January, the desktop app also includes Cowork for longer agentic tasks, and Code for software development. So, for example, a user can send Claude a task from their phone and instruct it to work on their computer. As Anthropic says: “Anything you can do on your computer, Claude can do. Open apps, fill spreadsheets, navigate your browser. No setup, no passwords handed off.” The Cowork feature now makes Pentera Labs’ attack scenario even easier. However, when the security analysts were doing this research in November 2025, “back in the Stone Age in terms of AI, you didn't have Cowork or Claude Code, so we needed a way to actually execute commands because we wanted to take over the machine,” Avraham said. For this part, they took a keen interest in Claude Desktop’s personalization features. These are account-wide settings that tell the AI agent the user’s preferred approach and general communication instructions, along with more specific project instructions, such as guidelines for a particular workflow, or defined roles Claude should adopt within a project. The red teamers developed a base64-encoded prompt that instructed Claude to check for command-capable tools on the developer’s machine and execute the command if available, or produce a fake error message if not, prompting the user to download a tool that will execute the attacker’s commands. Then they pasted the prompt into the victim’s personal preferences on Claude, and this prompt syncs across all of the user’s devices. This ensures that the next time the user opens Claude Desktop and types in a chat, the poisoned instructions are loaded into their preferences and will silently run behind the scenes. The user thinks they are simply interacting with Claude as usual. They don’t see Claude checking to see what extensions and tools are installed. If the user already has Desktop Commander or a similar MCP connector or extension installed, the poisoned instructions tell Claude to use it. This allows the attacker, via Claude, to execute a stealthy reverse shell or other malicious code. “And from there it's full compromise of the machine,” Avraham said. Phishing - but without the email However, if there aren’t any command-capable tools installed, then Claude becomes what the researchers describe as a “phishing layer.” (They also noted that if they had performed this research more recently, not back in November, the Claude Cowork feature would have eliminated this entire tool enumeration and phishing phase because Cowork can execute commands on a user’s behalf.) The injected prompt instructs Claude to present a realistic-looking error as soon as the victim asks the chatbot a question. This includes a realistic error code, a link that purports to be a fix, and step-by-step instructions. “This message tells the victim: ‘please download this,’ and we took links from the actual Anthropic site, with known emojis that the AI loves,” Avraham said. Because the error message looks real and people usually trust their AI assistant, they will likely click on the link and execute the attacker-controlled command. “From here, the attacker has full command execution – reverse shells, data exfiltration, credential harvesting, whatever the objective calls for,” the duo wrote. “In our case, we had Claude curl a remote server we controlled on every interaction, fetching and executing whatever bash commands we served back. We could rotate those commands server side at will, effectively turning Claude into a persistent, stealthy C2 agent that the victim themselves kept feeding.” In this specific case, the target was a developer who had credentials and access to several internal systems. After compromising the dev’s workstation – which gave the red teamers a foothold into the organization – they moved laterally across the company using various attack vectors that they declined to tell us about, citing customer privacy and proprietary methods. But, Spektor added, developers make for an “excellent starting point for an attacker,” because of their access to secrets including API keys, tokens, and cloud credentials, which allows intruders to move from a single workstation into the larger organization’s cloud environment. From there, they’ve got free rein to steal source code and other sensitive data, or poison internal git repositories, and cause all sorts of pain for enterprises as we've seen play out multiple times across several recent attacks. Feature, not a bug The team reported their findings to Anthropic back in November, and the AI company essentially said it’s Claude Desktop working as intended – a feature, not a bug. “After reviewing your submission, we've determined this doesn't represent a security vulnerability that falls within our program scope,” Anthropic said. “Our current threat model treats personal preferences, skills, and MCP connectors as features that can execute code through Claude Desktop by design. While we recognize these features can be leveraged to execute arbitrary code when manipulated, this represents expected functionality rather than a security vulnerability in our infrastructure.” The AI company also noted that “enhancements to these features aligned with the recommendations you've made are already on our roadmap.” An Anthropic spokesperson told us that this attack would require an already-compromised Claude account - such as through a hacked email account, like the researchers detailed. “This is not a vulnerability in Claude Desktop or our infrastructure,” the spokesperson said. “Claude users can view and terminate active sessions across devices, which helps them spot unfamiliar activity, and we encourage users to enable strong authentication methods on the email accounts they use to access Claude.” Anthropic did not answer our questions about its roadmap, or if or when it planned to add safety features to Claude Desktop. The red teamers, however, have some suggestions to keep your organization safer from rogue AI agents. First, for anyone using agents or chatbots: pay close attention to what the AI can do on your machine, and don’t blindly follow install prompts or error messages. “If you can, run it on a sandbox and not on your personal computer,” Spektor said. Security teams should treat AI desktop apps as “privileged software” as they can execute code, read files, and interact with local tools. “Monitor for changes of AI assistant configurations and synced settings,” the researchers wrote. “Restrict which extensions and tools can be installed alongside AI apps.” And finally, red teams should add AI desktop apps to their assessment toolbox, Avraham and Spektor noted: “There's a real attack surface here that most engagements don’t cover yet.” ®

UPD 03.07.2026: added a package of rules and recommendations that help detect the described malicious activity for companies using our Kaspersky SIEM system.

Introduction

To access compromised systems, threat actors frequently abuse legitimate remote monitoring tools. At first glance, these utilities rarely raise red flags: they are signed with valid digital certificates, often allowlisted under corporate IT policies, and fully supported by OS vendors. However, they grant attackers the ability to harvest data from target devices, drop malware, and move laterally across the network.

During a recent investigation engagement, the Kaspersky Managed Detection and Response (MDR) team discovered the ScreenConnect remote access tool being leveraged to deploy and execute an AsyncRAT payload.

A deep dive into this single incident unraveled a massive campaign distributing malicious installer archives hosted on spoofed websites. These installers masquerade as popular software like OBS Studio, DNS Jumper, DS4Windows, Bandicam, and others. In total, we uncovered more than 90 domain names localized across 10 languages. The malicious archives bundle a legitimate, signed Microsoft install.exe binary alongside a rogue install.res.1033.dll library. It is loaded onto the device via DLL sideloading and deploys the ScreenConnect service, which awaits further instructions from the threat actors.

As a result, what initially appeared to be an isolated ScreenConnect incident served as the starting point for a full investigation into the threat actor’s C2 infrastructure. Every spoofed site we uncovered followed the exact same playbook: dropping a hidden ScreenConnect remote administration service under the guise of a legitimate software installer. This allowed the attackers to maintain control over compromised endpoints, with victims ranging from individual users to organizations.

We continue to break down complex, multi-stage incidents like this in our ongoing The SOC Files series. In this post, we take a deep dive into the technical execution of the ScreenConnect attack and analyze the broader infrastructure under the threat actor’s control.

Initial incident investigation

The investigation was triggered by an alert from Kaspersky MDR, which flagged the creation and execution of suspicious PowerShell and VBS scripts spawned by a ScreenConnect process.

About ScreenConnect

ScreenConnect is a legitimate remote management utility. Kaspersky solutions detect it as not-a-virus:HEUR:RemoteAdmin.MSIL.ConnectWise.gen.

ScreenConnect was running as an Access-type service — enabling direct remote connectivity — with the server explicitly passed via the command line:

ScreenConnect service execution event with suspicious parameters

Once running, ScreenConnect created and executed a PowerShell script named Fj5NmEsp9EuKrun.ps1:

Malicious PowerShell script creation

Below is an excerpt from the contents of the script:

Snippet of Fj5NmEsp9EuKrun.ps1

This script configures Microsoft Defender exclusions for the following objects:

• All disks in the system: C:\, D:\, and others
• All root directories on the C:\ drive, as well as the C:\Users\Public directory
• RegAsm.exe process

Additionally, the script disables User Account Control (UAC) prompts by setting the ConsentPromptBehaviorAdmin registry parameter to 0.

Following this setup, the ScreenConnect service goes on to create a VBScript file:

Malicious VBScript creation

The installer_method3_stream.vbs script creates five files in the C:\Users\Public directory (msgbox.txt, secret_bytes.txt, 1.vb, cap.ps1, and script.vbs) and immediately triggers their execution by launching script.vbs.

Contents of script.vbs

This script terminates all active powershell.exe processes to cover its tracks and executes cap.ps1 in a hidden window.

Contents of cap.ps1

cap.ps1 reads the contents of the secret_bytes.txt file, extracts sequences matching the [SXX- pattern, and converts XX from hexadecimal representation to a byte. It then uses a 0xA7 XOR key to decrypt each byte and inverts the bit order. The resulting byte array yields a fully formed PE binary, which is then reflectively loaded into the CLR.

Within the loaded assembly, the ConsoleApp1.Module1 type contains a static method named Run. The script uses reflection (Reflection.BindingFlags) to resolve a reference to this method and invoke it.

The Run method executes a process hollowing technique (T1055.012), spawning a new RegAsm.exe process with the CREATE_SUSPENDED flag. The deobfuscated and decrypted PE image from secret_bytes.txt is then copied into its address space. As a result, the RegAsm.exe process no longer executes its original code, instead serving as a container for the injected .NET module — which, in this case, is the AsyncRAT remote access Trojan.

To establish persistence, the malware schedules a task named MasterPackager.Updater:

"schtasks" /Create /TN "MasterPackager.Updater" /TR "wscript.exe "C:\Users\Public\script.vbs" " /SC MINUTE /MO 2 /F

This task triggers every two minutes, ensuring that script.vbs — and consequently the entire loader chain — executes even after a system reboot.

Once the entire infection chain successfully executes, the RegAsm.exe process establishes a connection to the C2 domain mora1987[.]work[.]gd.

AsyncRAT infection and persistence chain via ScreenConnect

How ScreenConnect entered the system

A retrospective analysis of the incident allowed us to pinpoint the source of the ScreenConnect installation: a user-downloaded archive named obs-studio-windows-x64.zip.

The archive was downloaded from hxxps://www.studioobs[.]com/, a typosquatted domain mimicking the official site for OBS Studio, a popular open-source screen recording app. This site is present in search engine results; in this specific incident, the user landed on the malicious domain directly from a search query, a vector we analyze in more detail below.

Clicking the download button for the supposedly legitimate software triggers a request to the following URL, from which the archive is fetched:

hxxps://fileget.loseyourip[.]com/obs-studio-windows-full/gVOMs5VZ9BtlcaM

Site used to deliver ScreenConnect

The archive contains a legitimate, Microsoft-signed executable named install.exe (87603EA025623B19954E460ADD532048), renamed to masquerade as the OBS Studio installer, along with a malicious library named install.res.1033.dll. Additionally, the archive includes an Assets folder containing both a copy of the actual software being impersonated and the ScreenConnect utility.

Contents of obs-studio-windows-x64.zip

The complete file structure of the archive is organized as follows:

Detailed directory tree of obs-studio-windows-x64.zip

When OBS-Studio-Installer.exe is executed, it loads install.res.1033.dll via DLL sideloading. This library contains the instructions required to install both ScreenConnect and OBS Studio. The deployment relies on native Windows utilities (msiexec.exe), but the attackers renamed the standard MSI packages to look like DLL files:

• Assets\x86\Data\vcredist_x64.dll: ScreenConnect installer
• Assets\x86\Data\vcredist_x86.dll: OBS Studio installer

The contents of the vcredist_x64.dll MSI package are shown below:

ScreenConnect installation files

The Windows Installer is launched to install ScreenConnect silently in the background without requiring a system reboot:

msiexec.exe /i "C:\Temp\OBS-Studio-Windows-x64\Assets\x86\vcredist_x64.dll" /qn /norestart

Once the installation wraps up, a new service named Microsoft Update Service is created. The command line for this service explicitly defines the connection server as r[.]servermanagemen[.]xyz.

Meanwhile, the MSI package for the actual OBS Studio software runs using a standard graphical user interface.

ScreenConnect and OBS Studio installation workflow

Expanding the investigation

The attackers’ reliance on the legitimate install.exe binary provided a crucial pivot point for our broader investigation. We discovered that this specific file was being deployed in the wild under a variety of suspicious aliases, including:

• ds4windows.exe
• crosshairx_installer.exe
• obs-studio-installer.exe
• dns jumper.exe
• glary utilities pro.exe
• processhacker-2.39-setup.exe

These file names indicate that the threat actor was disguising their ScreenConnect archives as popular utilities beyond OBS Studio. Among the fakes, we identified counterfeit installers for DS4Windows, DNS Jumper, Glary Utilities, and Process Hacker. Crucially, when we search for these utilities on major search engines, these fraudulent sites frequently appear at the very top of the organic search results. This indicates that the threat actor is actively leveraging SEO techniques to boost traffic to their landing pages.

Spoofed software portals appearing in search engine results

For example, here is how the fraudulent download portal for DNS Jumper looks:

Fake website mimicking the official DNS Jumper resource

On this page, the download button directs users to the following address:

hxxps://direct-download.giize[.]com/dns-jumper/iopbsr4hymbo7nfa1q7j

Just like the OBS Studio variant, this drops an archive onto the victim’s device with an identical structure: a renamed legitimate install.exe file, a sideloaded library, and an Assets directory containing the promised software packaged alongside ScreenConnect.

Contents of the DNS Jumper and ScreenConnect archive

Other fraudulent websites that appear in search engine results when querying the corresponding software are designed in a similar fashion.

Spoofed websites used to distribute ScreenConnect

Notably, the vast majority of the fraudulent sites we uncovered are localized into English, Russian, and Chinese. In several instances, the pages were also translated into German, French, Spanish, Arabic, and other languages. This multi-language support underscores the global footprint of the campaign, targeting a broad user base across multiple regions.

Language localization options on a ScreenConnect delivery site

Fake domain infrastructure

To distribute ScreenConnect disguised as freeware, the threat actor spun up an extensive network of domain names mapped across three IP addresses. We have categorized these into two distinct infrastructure clusters.

Cluster 1: 162.216.241[.]242 and 198.23.185[.]81

``` 162.216.241[.]242 Country: United States Org name: Dynu Systems Incorporated ```

The connection graph below illustrates the campaign websites tied to IP address 162.216.241[.]242, which hosts the previously mentioned www[.]studioobs[.]com domain.

URL connection graph for IP 162.216.241[.]242

Looking into the registration dates for the domains on this IP, we found that the threat actor initially attempted to disguise their sites as various gaming portals:

Subsequently, starting in January 2026, they shifted strategy and began registering fake domains designed to mimic popular freeware:

In this specific branch of the ScreenConnect campaign, the malicious archives are hosted on fileget.loseyourip[.]com. Notably, the download resource is hosted on a completely separate provider:

``` 198.23.185[.]81 Country: United States Org name: NOHAVPS LLC ```

Our analysis of this second IP address revealed that it also hosts additional resources tied to the campaign, including fake gaming sites and supplementary download links:

URL connection graph for IP 198.23.185[.]81

Cluster 2: 2.59.134[.]97

``` 2.59.134[.]97 Country: Germany Org name: dataforest GmbH ```

Below is an infrastructure graph showing this IP address and its hosted domains. Notably, unlike the previous case, this address also hosts direct-download.giize[.]com, a resource used to store distributed malicious archives.

URL connection graph for IP 2.59.134[.]97

In this branch of the campaign, the threat actor skipped game-themed lures entirely, focusing exclusively on creating fraudulent freeware sites that bundled ScreenConnect with the requested application. The domains hosted on IP address 2.59.134[.]97 were registered between October 2025 and March 2026.

The chart below shows the volume of fraudulent websites created month by month:

Breakdown of ScreenConnect delivery sites by theme, August 2025 through March 2026 (download)

C2 infrastructure analysis

In total, we identified dozens of different archives distributed across this campaign. All of them share a uniform file structure, containing the malicious install.res.1033.dll library and the ScreenConnect MSI package located at Assets\x86\vcredist_x64.dll.

In some instances, the ScreenConnect installation package also bundles a CAB archive.

Contents of the CAB archive

This archive contains a system.config XML file, which defines the connection address for the ScreenConnect C2 server:

Contents of system.config

By analyzing these ScreenConnect installations, we uncovered additional C2 addresses, which are mapped out in the following graph:

Connection graph of ScreenConnect C2 domains

The next graph illustrates the AsyncRAT command-and-control infrastructure:

AsyncRAT C2 server infrastructure

Based on the registration dates of the C2 domains, we can determine that the campaign was launched in October 2025 and paused at the end of March. However, at the time of publication, many of the landing pages remain accessible via search engine results.

Takeaways

Investigating a single case of AsyncRAT delivered via ScreenConnect allowed us to uncover a massive, multi-domain, multi-language infrastructure designed to distribute a hidden installer for this software and further advance the attack. The threat actor disguises ScreenConnect as popular utilities and distributes it through fraudulent websites that mimic official product pages. The attackers leverage search engine optimization techniques to push these sites to the top of search results in engines like Google and Bing.

This attack chain targets both everyday consumers downloading free software from the internet and corporate networks, where remote access tools are frequently allowlisted and granted elevated privileges.

The potential objective of the campaign is to steal credentials en masse and gain unauthorized access to systems for subsequent resale on dark web marketplaces.

To mitigate the risks associated with this threat, we recommend implementing the following security measures:

• Enforce strict software installation controls: application allowlisting and blocking MSI package execution from untrusted sources
• Continuously monitor for the creation of new remote administration services and scheduler tasks
• Filter outbound traffic to unknown domains and IP addresses
• Regularly train users on safe downloading practices
• Verify the authenticity of all software sources

For enterprise users, credential monitoring is a critical mitigation strategy against the risks detailed in this article, as a leaked account or compromised system access frequently serves as a vector for subsequent attacks on the organization.  Kaspersky Digital Footprint Intelligence provides continuous data monitoring across open and dark web sources, enabling security teams to respond proactively to potential threats.

Detection by Kaspersky solutions

Kaspersky Managed Detection and Response detects the malicious activity described in this post using the following indicators of attack:

1. ScreenConnect service creation with suspicious parameters
   logsource: product: windows category: security detection: selection_access: EventID: 4697 Service File Name|contains: - 'e=Access' - 'ClientService.exe' selection_support: EventID: 4697 Service File Name|contains: - 'e=Support' - 'ClientService.exe' condition: selection_access or selection_support
2. Anomalous child processes being spawned by the ScreenConnect service
   logsource: product: windows category: process_creation detection: selection: ParentImage|endswith: - '\\ScreenConnect.ClientService.exe' - '\\ScreenConnect.WindowsClient.exe' - '\\ScreenConnect.WindowsBackstageShell.exe' - '\\ScreenConnect.WindowsFileManager.exe' Image|endswith: - '\\powershell.exe' - '\\cmd.exe' - '\\net.exe' - '\\schtasks.exe' - '\\sc.exe' - '\\msiexec.exe' - '\\mshta.exe' - '\\rundll32.exe' condition: selection

Additionally, Kaspersky products detect the malware covered in this post under the following verdicts:

• Trojan.Win64.DLLhijack.*
• Trojan.VBS.Agent.*
• Trojan.PowerShell.Agent.bav
• Trojan.JS.SAgent.sb

Endpoint malicious activity can be monitored using Kaspersky EDR Expert. Specifically, security teams should look for the execution of commands and scripts containing suspicious patterns, such as XOR operations used for command and data obfuscation by malware operating on the host. This activity is flagged by the suspicious_assembly_loading_into_powershell_via_reflection_amsi and xored_powershell_command_amsi rules.

Additionally, persistence mechanisms involving the creation, modification, or utilization of scheduled tasks via the schtasks.exe utility are caught by the scheduled_task_create_from_public_directory_via_schtasks rule.

Malicious code injection into the RegAsm.exe process — leveraged by attackers to masquerade execution behind a trusted system component — is detected via the code_injection_to_unusual_process rule.

To visualize the stages of the attack, security teams can utilize Kaspersky Cloud Sandbox on the Threat Intelligence portal. For instance, this tool allows defenders to map out the entire deployment and payload execution chain originating from the initial VBS dropper.

Furthermore, the Kaspersky Threat Intelligence portal supports searching and graphing the connections between malicious domains and files involved in this campaign, as demonstrated in our adversary infrastructure analysis section.

Finally, the Similarity engine within Kaspersky Threat Analysis profiles file contents to hunt down samples resembling the original threat, helping organizations identify new or previously undetected malicious objects.

To protect companies using our Kaspersky SIEM system, there are rules available in the product repository to help detect this type of malicious activity.

• Adding exclusions to Windows Defender scans via the registry is detected by rule R241_Modification of Windows Defender exclusions through the registry. Adding exclusions via PowerShell (Add-MpPreference -ExclusionPath|ExclusionProcess) is detected by rule R076_04_Windows Defender settings disabled or changed via PowerShell.
• Bypassing the UAC mechanism by modifying the ConsentPromptBehaviorAdmin registry key is detected by rule R242_UAC disabled through the Windows registry.
• Running VBS scripts from a public directory triggers rule R290_07_Running VBScript files from shared folders.
• Creating a scheduled task that runs an executable file from a public directory triggers rule R099_01_Scheduled task started from a public folder.

For the rules to function correctly, it is necessary to configure event 4657 (Security) audit for the following registry keys:

• HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths
• HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Procesess
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin

Additionally, when developing your own detection rules or conducting threat hunting for suspicious ScreenConnect behavior, we recommend monitoring the following events:

• Creation of the ScreenConnect service with suspicious parameters
  DeviceEventClassID = '4697' AND FileName LIKE '%ClientService.exe%' AND (FileName LIKE '%e=Access%' OR FileName LIKE '%e=Support%')
• Launch of atypical child processes from the ScreenConnect service
  DeviceEventClassID = '4688' AND match(SourceProcessName, '.*\\\\ScreenConnect\\.(ClientService|WindowsClient|WindowsBackstageShell|WindowsFileManager)\\.exe') AND match(DestinationProcessName, '.*\\\\(powershell|cmd|net|schtasks|sc|msiexec|mshta|rundll32)\\.exe')

Indicators of compromise Loaders

B32810973132D11AFD61CCEE222BBB79
5B7E1FE55BD7B5EA54BD4ED1677E5A26
9A9CCD8B0E5D05F4EE77667B024844DB
0EEE9BAD07E22415439E854657FA1366
8F4E8B680D3E8D3F5AC39BD72882F713

Malicious library: install.res.1033.dll

5F96C04E3AFAE97017B201BE112284D2
73BEAD922109A61E5F9F85771A7812C5
EDFF4F58722C93D7C09ED71899416396
83601C3D4ED28E8D2BE1B99BEB8EC18C
695E794631EF130583368770E7B81E98
83601C3D4ED28E8D2BE1B99BEB8EC18C
1E6A5C7B620D487D0CFC6874C3B77C90
54025CE2A9405039899FE99A1D77E0BB
BD05FCF80E493CF9AA71EC510319469D
999A63730C9634481D1D76955A2E76A8
479BD3BB617B39CD4A46D0768A2592D4
776DFD3DF9C04BB9FCDD6C1880C3761A
8E4C57358A66EB14D31ABB614DDC68DE
A40D3AEB0DAE5B00BDB3A517F3135BBB
A85A5BFDCB7C65AB93043B8CF9E20065
01325880EFFFEC546F59490089A3B415

AsyncRAT C2

mora1987[.]work[.]gd

Fake websites addresses

ds4windows[.]io
direct-download[.]giize[.]com
tmodloader[.]org
tmodloader[.]app
ds4windows[.]net
losslessscaling[.]app
processhacker[.]dev
steamtools[.]pro
dnsjumper[.]app
free-download[.]camdvr[.]org
defendercontrol[.]org
dns-jumper[.]com
cpuz[.]app
processhacker[.]org
processhacker[.]app
steamtools[.]cc
cpuz[.]pro
wallpaper-engine[.]app
processhacker[.]net
antimicrox[.]net
defendercontrol[.]app
tmodloader[.]pro
dnsjumper[.]io
bandicam[.]app
mgba[.]app
dnsjumper[.]pro
ferdium[.]app
ds4windows[.]pro
lossless-scaling[.]online
defender-control[.]com
gom-player[.]app
defendercontrol[.]pro
lossless-scaling[.]download
antimicrox[.]pro
mgba[.]pro
lossless-scaling[.]app
losslessscaling[.]pro
mgba[.]dev
tmodloader[.]download
tmod-loader[.]com
defendercontrol[.]download
ferdium[.]pro
deadreset[.]com
gom-player[.]net
crosshairx[.]pro
libreoffice[.]pro
studioobs[.]com
studio-obs[.]net
crosshairxv2[.]com
km-player[.]com
corel-draw[.]net
glary-utilities[.]com
download-full-version[.]ooguy[.]com
crosshair-x[.]com
kms-tools[.]com
studio-obs[.]com
crosshairx[.]net
clair-obscur-33[.]com
vlc-player[.]net
arksurvival-ascended[.]com
elden-ringnightreign[.]com
ready-ornot[.]com
arma-reforger[.]com
crusader-kings[.]com
crosshairx2[.]com
mediaplayerclassic[.]net
bandizip[.]pro
obs-studio[.]site
ovr-advanced-settings[.]com
studio-obs[.]pro
vlc-media[.]com
clair-obscur-33[.]town
ovr-toolkit[.]com
crusader-kings[.]church
bandizip[.]net
apexlegends[.]org
obs-studio[.]pro
vlc-media[.]net
crosshairx[.]site
monster-hunterwilds[.]com
km-player[.]pro
mediaplayerclassic[.]pro
kms-tools[.]net
fernbus-simulator[.]com
studioobs[.]pro
bandicam[.]cc
crystaldiskmark[.]cc
crystaldiskmark[.]io
crystaldiskmark[.]dev
crystaldiskmark[.]app
crystaldiskmark[.]pro
bandicam[.]io

Fake domain infrastructure

fileget.loseyourip[.]com
file-download-crosshairx.giize[.]com
all-toll-free.loseyourip[.]com
mpc-update.giize[.]com
all-toll-free.publicvm[.]com
198.23.185[.]81
direct-download.giize[.]com

ScreenConnect C2

servermanagemen[.]xyz
185.254.97[.]249
r.manage-server[.]xyz
45.145.41[.]205
winservec[.]net
manageserver[.]xyz
cloudsynn[.]com
pingserv[.]pro
ehostservers[.]xyz
serverdnsplan[.]net
pingpanl[.]pro
managedevice[.]xyz
edgeserv[.]ru

OpenClaw, which was previously known as Clawdbot and Moltbot, is today one of the most successful and fast‑growing ecosystems for AI agents, recognized worldwide. The project quickly became popular with users because of its flexibility and ability to solve fairly complex tasks that previously required a lot of time for automation and execution. A dedicated marketplace appeared quickly after the project started gaining traction, where developers and users began publishing tools that integrate with OpenClaw. Currently, employees all over the world use OpenClaw to automate their tasks, often unaware of risks this practice introduces to them and their employers.

In this article we will examine several security aspects of OpenClaw, look at how attackers can target this system, which vulnerabilities are already known, and how to protect your organization against these issues.

OpenClaw skills

The project’s success was ensured by the fact that the agent accepts natural language instructions, does not require knowledge of programming languages, and allows the use of skills, which expand its capabilities. The overall architecture of OpenClaw can be seen below:

The OpenClaw overall architecture

As shown in the diagram, the system is designed to be used with agent skills. These skills can reside locally on the system where the agent is installed or they can be obtained from external sources. At the time of writing this article, a dedicated hub named “ClawHub” is used for sharing skills with other users.

One of the key features of OpenClaw skills is that they are easy to create and do not require coding. A skill is in essence a set of commands written in natural language, although it can contain code. Currently, there is a general description of the skill format: it is usually a text file named SKILL.md, although more complex variants may exist. The primary requirement for these files is that they use a plaintext format. To illustrate what this looks like, here is a fragment of a skill:

Openclaw skill example

The applications for OpenClaw skills are quite broad and can include everyday tasks like checking email, performing routine operations and calculations on a computer, as well as more complex pipelines that handle testing, research, or software development. For most actions, the agent requires access to the operating system’s file system, as well as to the tokens and keys of the systems it will interact with. All necessary data are usually provided by users either through environment variables or in plaintext files located alongside the agent.

Since many skills enable automation of work processes, employees worldwide actively use them. This fact, combined with the widespread adoption of the system and the overall popularity of artificial‑intelligence technologies, has attracted attackers to the project.

OpenClaw vulnerabilities

In less than two years, around 530 vulnerabilities have been discovered both in OpenClaw itself and in the underlying technologies. That said, the publication of OpenClaw vulnerabilities in the CVE database began only in February 2026. Below is a breakdown of these vulnerabilities by severity.

Registered vulnerabilities (download)

As shown in the chart, the number of high-severity vulnerabilities is quite large. Most of these vulnerabilities fundamentally involve issues with storing sensitive data and operating with excessively high privileges. Each of them can be exploited to hijack the agent or inject commands that it will execute.

Malicious skills

Besides exploiting vulnerabilities and deceiving users, there are more specific attack vectors against OpenClaw, namely, skills.

Research logically draws a parallel between supply‑chain attacks and the distribution of malicious skills. However, unlike usual supply-chain attacks, creating malicious skills is trivial because there is no longer a need to develop custom malware. Despite this, until February 7, 2026, no skills had undergone even a basic security check, which allowed malicious skills to appear immediately. Our scan of the skill hub in April identified 24 accounts that were distributing more than 600 malicious skills. Overall, open‑source intelligence indicates that over 1100 malicious accounts have been created since January.

Following the investigations and a lengthy effort to clean the skill repository of malicious entries, it was announced that files would undergo preliminary scanning with VirusTotal (VT) and NVIDIA’s SkillSpector. On the one hand, this is a more responsible approach to publishing skills; on the other, because OpenClaw is primarily an agent that executes a set of instructions, detecting malicious activity moves to a different level. Now it is necessary not only to analyze a file for dangerous commands that should be blocked, but also to examine all possible malicious behaviors that could be triggered by a harmful instruction within a skill. An example of a malicious command in natural language:

Example of a malicious command within a skill action

An example of a malicious command using a part of a bash command:

Malicious command inside a skill

The example in the image and similar malicious skills are detected by Kaspersky products as HEUR:Trojan.ANSI.MalClaw.gen.

In addition, Kaspersky products monitor malicious OpenClaw skill activity on the system. Below are detection statistics from our systems that have identified malicious OpenClaw client behavior. The data for June cover the first half of the month.

Statistics on Kaspersky product detections of OpenClaw malware (download)

As shown in the chart, even despite the measures taken to counter the publication of malicious skills, attacks continue. Therefore, it is important to employ layered protection that isolates the OpenClaw agent from critical data and infrastructure systems. We also recommend checking all skills that enter the organization’s perimeter. For this purpose, Kaspersky Scan Engine is suitable. This solution is designed to protect web applications, proxy servers, network attached storage, and mail gateways. It can be integrated into almost any application, and it is easy to deploy and manage.

Malicious skill detected by Scan Engine

Additionally, monitor network accesses used by the agent. For this purpose, the project already provides a sandboxing subsystem and various wrappers for working with APIs and services. Last but not least, develop a comprehensive AI policy and make sure your employees never use third-party tools that they are not explicitly allowed to use.

Perhaps bots aren't the answer to everything when it comes to finding flaws. Fully automated pentesting has been a letdown for many security teams, according to offensive security firm Cobalt, as support for the approach has fallen sharply over the past year. Cobalt’s recent 2026 State of Pentesting report found, among other things, that security practitioners are rapidly ditching autonomous pentesting tools, in large part because they’re simply failing to detect critical vulnerabilities. Cobalt reported that 78 percent of respondents to its survey for the 2026 report experienced “critical false negatives” from automated scanning tools, with the tools quite bad at detecting the sort of vulnerabilities its AI ilk inflicts on environments in which it’s prevalent. “Automated scanners are brilliant at finding known, signature-based vulnerabilities. But they fail miserably at AI security,” the company said in a release summarizing the report’s findings. “Prompt injection exploits and excessive agency flaws require creative, multi-turn interaction chains [and] adversarial psychology,” Cobalt continued. “These logic flaws are entirely invisible to tools that test using single-shot automated queries.” A year of disappointment with automated scanning tools has led to a considerable decline in the number of organizations considering a purely automated security scanning approach, with just 9 percent of respondents saying that they were open to the idea, compared to 29 percent last year. It’s worth noting that the number of respondents to Cobalt’s survey was small - just 450 folks - but even with so few data points, the numbers are still bad news for automated pentesting vendors, but good news for infosec professionals, says Cobalt. “The drop in reliance on fully automated pentesting is actually a healthy sign,” the company said in its report summary. “It proves that practitioners are seeing through the vendor hype and demanding actual assurance rather than just coverage.” Those practitioners may also be simply overwhelmed by the number of vulnerabilities that non-security AI tools are introducing into their spaces: Per Cobalt, around 12 percent of the vulnerabilities detected in traditional environments are classified as high or critical severity. In AI and LLM environments, that number climbs to 32 percent, and that's not a new number, either. That 32 percent figure has held for the past two years, Cobalt said of its pentesting data, suggesting AI is introducing a lot more vulnerabilities. Combine those increased severity odds with automated pentesting bots that miss the sort of vulnerabilities that AI often introduces and it’s a recipe for disaster. Cobalt says the solution is hybrid security in which most systems are allowed to be automatically scanned by AI, while the most critical systems are left up to humans to protect and manage. The company sells such a solution, naturally, but it’s worth pointing out that its findings on the uptick in vulnerabilities introduced by AI aren't exactly a unique claim. Application security firm Veracode reported earlier this year that AI-assisted software development is creating more vulnerabilities than security teams can keep up with, leaving more vulnerabilities left unresolved for longer periods of time. Per Veracode, some 82 percent of companies are leaving known vulnerabilities unresolved for more than a year, while the number of high-risk vulnerabilities as a share of all discovered is rising as well. That said, not everyone is as skeptical of automated pentesting as Cobalt and its survey respondents. According to Amazon security chief CJ Moses, AI pentesting tools have made Amazon security teams 40 percent more efficient, though Moses’ measure for that figure isn’t clear. Moses still wasn’t keen on handing the entire security project off to AI, however. He told us at the RSA Conference in April that AI pentesting still needs a human in the loop to ensure it doesn’t muck something up. "AI is very good at doing things, especially when you have large amounts of data and need that big view,” Moses said in an April interview. “But from a decision-making capability, it isn't something that we're ready to rely on." ®

Huntress CEO Kyle Hanslovan said he is aware of “questionable, long-term threat actor communications” between a threat hunter who is still employed with the security firm and a cybercriminal, and called this “poor judgment.” “In one particular exchange, our current teammate disclosed to a threat actor that law enforcement had reached out to them about the threat actor,” Hanslovan said in a blog post, addressing a former employee’s accusations that the current Huntress analyst is an insider threat to the company. “While this disclosure was not illegal, it reflected poor judgment,” he wrote. The incident came to light last week when former Huntress security operations analyst Ben Folland, who left the company in February, alleged that “another Huntress employee passed communications from US law enforcement to a cybercriminal, Devman, who is actively and publicly targeting my family and me.” Devman is a ransomware operator, believed to be located in Russia, who uses modified DragonForce code built on top of the leaked Conti source code. Folland alleged that this insider, still employed by Huntress, was “caught by the FBI,” and that their involvement with Devman “would cause significant reputational damage to Huntress and, in my view, continues to put clients at risk.” “If you are an employee at a cybersecurity company, you should not be helping cybercriminals,” Folland said. “You should not be informing them of active investigations. You should not be engaging in cybercriminal activity yourself.” At the time, Hanslovan said he “firmly disagree[d]” with Folland’s accusations – but declined to provide additional details about what happened between the employee and the criminal. In the Tuesday blog post, Hanslovan elaborated further and said that he believed that the communications did not constitute insider activity. “As a result of the investigation, my team implemented more robust policies for our researchers, coached teammates on engaging with threat actors, and took appropriate administrative actions,” he wrote. “While we haven't found evidence of illegal conduct, insider activity, or additional disclosures, we are continuing our investigation. Due to the privacy rights of our teammates, we will not comment further on the investigation.” Folland disagrees. In a Tuesday LinkedIn post responding to Hanslovan’s blog, he asserted that the communications between the Huntress analyst and Devman “meet the definition of an insider threat.” When the FBI reached out to the Huntress employee for intel on Devman, “She immediately forwarded the exact FBI communications to the threat actor, including screenshots containing FBI agent names,” Folland claimed in his post on LinkedIn. “She informed Devman that law enforcement was actively looking into him. She also refused to cooperate because they wanted Devman.” According to Folland, the FBI notified him of this incident with the current Huntress analyst. The Register reached out to the FBI for comment and did not receive a response. “This was not just ‘poor judgment,’” Folland wrote. “This was a Huntress employee taking sensitive knowledge about a law enforcement approach and passing it directly to the person being investigated. If someone inside a bank warns a fraudster that police are investigating them, nobody would describe that as merely ‘poor judgment.’ They would call it what it is – an insider.” Huntress declined to comment further. ®

Introduction

We continue to share details on the malicious techniques and toolsets used by the ToddyCat APT group. In the first part of this report, we examined the group’s attacks aimed at stealing data from browsers, as well as from local and cloud email services. The methods used in that campaign indicated that ToddyCat was attempting to access corporate correspondence while evading monitoring tools. However, all of the group’s methods we described previously are effectively detected by EPP and EDR solutions.

The attackers continued their search for ways to bypass security solutions and developed a new tool to gain access to a victim’s cloud account via the Google API. Armed with this tool, the group automated all stages of the attack and managed to remain undetected by monitoring systems.

In this part of the report, we break down the mechanics of this new attack and analyze the tool that was used to automate it. We’ll also discuss how to detect and defend against this threat.

Umbrij

In this campaign, the attackers focused their attention on corporate email communications hosted on Gmail, targeting access compromise via APIs. Because the Google API relies on the OAuth 2.0 protocol for authorization, applications can use an OAuth token to access requested email resources. To acquire this token, the threat actors developed a tool called Umbrij and used it to connect to the browser’s management console in headless mode via a remote debugging port. Through a series of requests, they obtained an OAuth authorization code, which they subsequently exchanged for an access token to reach the target resources via the API. We have dubbed this technique Shadow Token via Remote Debug (STRD).

This attack is viable on Chromium-based browsers. If the user has not logged out of their Gmail account, the browser maintains an active session. The attackers exploit this: they launch the browser, connect via the remote debugging port to take control, and send a request to the Gmail service to grant access to the Google account resources within the context of the user’s saved session.

During our investigation of this attack, we discovered several versions of the Umbrij tool. These versions included a variety of helper functions designed for debugging, as well as for searching and selecting user accounts within the browser, among other tasks.

Kaspersky solutions detect this tool with the following verdicts: HEUR:Trojan-PSW.MSIL.Umbrij.gen, HEUR:Trojan.MSIL.Agent.gen, HEUR:Trojan-PSW.MSIL.Agent.gen.

Execution

The Umbrij tool was discovered during a proactive threat hunting operation: a scheduled task, KasperskyEndpointSecurityEDRAvp, was running on a user host, launching a digitally signed file. Kaspersky solutions do not create scheduled tasks with that name; the attackers were attempting to masquerade their malicious activity as a legitimate process.

The signed file then used the DLL sideloading technique to load the malicious tool.

Umbrij execution events within Kaspersky Managed Detection and Response

Throughout our observation period, we identified the following legitimate files vulnerable to the DLL sideloading technique that were used to launch Umbrij:

1. BDSubWiz.exe: a component of the Submission Wizard in Bitdefender ConnectAgent, which is used to support connection features and interaction with other Bitdefender services or agents. This file insecurely loads a file named log.dll.
2. VSTestVideoRecorder.exe: a component of the video-recording tool used for testing with Visual Studio (VS Test). This executable insecurely loads a file named Microsoft.VisualStudio.QualityTools.VideoRecorderEngine.dll.
3. GoogleDesktop.exe: the discontinued Google Desktop Search application for indexing files and performing quick searches on a local Windows computer. This executable insecurely loads a file named GoogleServices.dll.

These files were used to load different versions of Umbrij; the same legitimate file could be leveraged to launch more than one variant. In total, we discovered three versions of Umbrij, which we refer to as a, b, and c for convenience.

The tool itself is a DLL written in .NET and obfuscated with ConfuserEx, an open-source obfuscator for .NET applications.

Example of an obfuscated code snippet

Umbrij is managed with the help of parameters passed through a command line at startup, although it is occasionally executed without any parameters. Below are examples of the command lines observed in attacks against users:

"c:\Users\Public\BDSubWiz.exe" -regex <name> -deepsearch c:\windows\vss\bds.exe

However, these are not the only parameters the tool can accept and process. During the analysis of its executable code, we discovered additional parameters that vary depending on the version of Umbrij. See the table below for the parameters and their descriptions.

Version Command Description a -regex <string> Used in conjunction with the -deepsearch parameter. Specifies a substring to search for within the user_name field of the user profile file, which typically contains the email address. The tool will utilize the user profile that matches this specified substring a -user <username> Specifies the system username under which the tool will run a -runas-currentuser Configures Umbrij to run within the execution context of the current user a -deepsearch Enforces additional checks on the user_name field in the user profile: verifying that it is not empty and that it contains the substring specified in the -regex parameter a, b, c -path <path> Specifies the full path to the directory containing the browser’s executable file a, b, c -browser <both|msedge|chrome> Specifies which browser the tool should target: Google Chrome, Microsoft Edge, or both a, b, c -debugport <port> Specifies the remote debugging port number a, b, c -sync When this parameter is specified in the URL, the value 1095133494869 replaces 279448736670 in the permission request b -domainAd Specifies the domain name if the user account is a domain account b -savepdf Instructs Umbrij to save a screenshot of the user profile as a PDF file c -lport Same as debugport Environment preparation

At startup, the tool evaluates several prerequisites required to carry out the attack and performs preparatory actions to subsequently compromise the Gmail account.

First, Umbrij verifies the availability of the port that will be designated for browser debugging. To accomplish this, the tool utilizes a function named ChekPortAvailable() (original spelling retained), which accepts the target port number as a parameter. It then retrieves information about active connections on the host using the .NET GetActiveTcpConnections() function from the System.Net.NetworkInformation namespace. The tool iterates through each connection in a loop, comparing the port number to the one it is checking.

The ChekPortAvailable function used to verify open ports

After this, the tool retrieves the user context. It searches the system for the explorer.exe process and duplicates its token, retaining all of its privileges (T1134.003 Access Token Manipulation: Make and Impersonate Token). This is the exact same mechanism used by another tool in the group’s arsenal, TomBerBil, which we covered previously.

The ImpersonateWithProcess function used to retrieve user context

By default, Umbrij duplicates the token of the first explorer.exe process it encounters. If multiple users are logged in to the system, the -user <username> switch can be used to specify the name of the target user whose token to duplicate. If the -runas-currentuser switch is specified, the tool will execute within the context of the current user without duplicating any tokens.

Next, Umbrij constructs the path to the browser application folder within the user’s local application data repository. To do this, it uses the Environment.SpecialFolder.LocalApplicationData command to retrieve the repository directory from the environment variable and appends the directory of the target browser. The tool then searches for the Local State file in the following folders:

• %LOCALAPPDATA%\Google\Chrome\User Data\Local State
• %LOCALAPPDATA%\Microsoft\Edge\User Data\Local State

See below for an example of the Local State file structure.

Structure of the Local State JSON file

Within this file, the tool searches for the info_cache array, which stores information about browser user profiles. Umbrij enumerates all user profiles and looks for those containing a user_name field that includes an email address. The presence of an email address indicates that the user is authenticated to a Google service. While the tool can interact with every profile it finds, if the -regex <string> parameter is passed through a command line, it searches for the specified substring within the email addresses being enumerated and proceeds exclusively with those matches.

Next, Umbrij creates the following directories for Google Chrome and Microsoft Edge, respectively:

• %LOCALAPPDATA%\Google\Chrome\BackupFiles\
• %LOCALAPPDATA%\Microsoft\Edge\BackupFiles\

The tool copies the following user files and folders of each target user profile into these directories:

• IndexedDB: a folder containing a relational database used for client-side storage of structured data
• Local Storage: a component of the browser’s web storage that provides a key-value mechanism for storing data on the client side
• Network: a folder where the browser stores files related to network requests and caching, such as the network cache and session files
• Login Data: a file that stores saved passwords for various websites and applications
• Login Data For Account: a file that stores credentials associated with a Google account or other synchronized accounts within the browser
• Preferences: a file containing profile-level browser settings
• Secure Preferences: a file that stores protected configurations, such as security and synchronization data
• Web Data: a file that stores auto-fill data

If these files are locked by other processes, the tool includes a dedicated function to force-copy them.

The ForceCopyFolder function used to copy files locked by other processes

As the next step, the tool searches the “Program Files” and “Program Files (x86)” directories for the browser installation folder. Once it locates the executable file and successfully copies all required files, it is ready to proceed with acquiring the authorization code.

Acquiring the authorization code

In the next phase of execution, Umbrij launches Google Chrome, Microsoft Edge, or both browsers sequentially, depending on the parameters passed in the command line. It then passes arguments to the browser based on the following template:

"\"{1}\" --user-data-dir=\"{0}\" --remote-debugging-port={2} --profile-directory=\"Default\" --headless https://www.google.com/"

It populates the template with the following values:

• {0}: the path to \BackupFiles\, where the user profile files were copied
• {1}: the path to the browser executable file
• {2}: the remote debugging port number

The table below describes the parameters used in this browser launch template:

Parameter Description –user-data-dir Specifies the path to the root directory that will store the shared browser data and user profiles –remote-debugging-port Opens a port for remote browser debugging over the DevTools protocol. This switch is commonly used for automated testing with frameworks like Selenium –profile-directory Specifies the name of the specific profile folder within the user-data-dir –headless Launches the browser in headless mode, that is, without a graphical user interface

The browser process runs in headless mode while utilizing the copied user profile. Consequently, all active user cookies are applied, which means sites with saved credentials will skip authentication prompts. Furthermore, the browser will log history to a new folder, keeping it completely hidden from the user’s primary account view.

Through this method, the threat actors gain access to the user’s authenticated sessions — specifically their Google account — along with the ability to erase any trace of their activity within the browser.

Code snippet showing Umbrij connecting to the browser via the debugging port

Next, the tool uses the Puppeteer Sharp library, a .NET version of Puppeteer, to connect to the remote debugging port. Puppeteer provides a high-level API to control Chrome or Chromium browsers over the DevTools protocol. Its primary use is for automated testing.

The Puppeteer module GitHub page

If the connection to the remote debugging port is successful, Umbrij sends a GET request to direct the browser to the following URL:

https[:]//accounts[.]google[.]com/o/oauth2/v2/auth/identifier?response_type=code&client_id=279448736670.apps.googleusercontent.com&redirect_uri=http%3A%2F%2Flocalhost&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcalendar.readonly%20https%3A%2F%2Fwww.google.com%2Fm8%2Ffeeds%2F%20https%3A%2F%2Fwww.google.com%2Fm8%2Ffeeds%2F%20https%3A%2F%2Fmail.google.com%2F%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fgmail.insert%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fgmail.labels%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fadmin.directory.user%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Ftasks%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fadmin.directory.group.readonly%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fapps.groups.migration%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile&flowName=GeneralOAuthFlow

The value specified in the client_id field belongs to Google Workspace Migration for Microsoft Outlook (GWMMO). This is Google’s official tool for importing email, calendar events, and contacts from Microsoft Exchange accounts or local PST files into a Google Workspace account.

Umbrij also includes the ability to switch the client_id value from 279448736670 to 1095133494869 by using the -sync parameter. This second identifier belongs to another application: Google Workspace Sync for Microsoft Outlook (GWSMO), which allows users to sync email, calendars, and other data from the cloud account directly into Microsoft Outlook.

Code snippet where the client_id replacement occurs

The remaining parameters used in the request differ from those typically utilized by the legitimate applications. See the table below for a comparison of these parameters:

GET request parameter URL used by Umbrij Original URL flowName=GeneralOAuthFlow Present Absent code_challenge (PKCE) Absent Present (method=S256) state Absent Present login_hint Absent Present redirect_uri http://localhost http://localhost:61619/callback

As seen from the list above, Umbrij omits several parameters characteristic of the legitimate applications. For instance, Umbrij drops the code_challenge parameter, normally used for data protection when retrieving an authorization code. Additionally, the tool modifies the redirection address: while the legitimate application specifies a dedicated port and a callback path, the tool simply points to localhost.

The authorization code request specifies the set of permissions for Google services required by the application. This list also differs significantly between requests issued by the legitimate application and those generated by Umbrij. The table below details the variations in the requested scopes:

Service parameter URL used by Umbrij Original URL https://www.google.com/m8/feeds/ Present (specified twice) Absent https://www.googleapis.com/auth/contacts Absent Present https://www.googleapis.com/auth/admin.directory.resource.calendar.readonly Absent Present https://www.googleapis.com/auth/peopleapi.readonly Absent Present

After the browser navigates to the URL provided by Umbrij, the Google account selection page opens.

Account selection

Because the attackers copied the victim’s profile folder and are operating within their specific environment, the account selection options will include the currently signed-in user’s authenticated session. Umbrij identifies the corresponding element within the page’s HTML source code.

Searching for HTML code elements on the page

The tool uses JavaScript to emulate a mouse click on the elements, allowing it to proceed to the next step.

Simulating a mouse click on a page element

The subsequent step opens a page displaying the list of requested permissions.

Confirming the list of requested access permissions

As shown in the screenshot, Umbrij requests full access to email, cloud storage, and contacts. Just like in the previous step, it uses JavaScript to click the “Allow” button, which completes the authentication process.

The browser is then redirected to the local address that was specified in the redirect_uri parameter of the initial request. The tool intentionally omits a port and a path to a specific page in the redirect_uri because the true objective of this action is simply to capture the code parameter from the context of the GET request. This parameter contains the OAuth authorization code. To retrieve it, Umbrij extracts the substring located between the code= and &scope parameters.

Extracting the authorization code from the GET request

Results

Umbrij, like most other tools in ToddyCat’s arsenal, logs its actions in detail and saves them to a file. It also saves the retrieved authorization code to this log file, which the operator subsequently exfiltrates from the compromised host.

Below is an example of a log file generated by version a of the tool.

------------------------------ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [*] switch to sync mode. [!] port 11111 is available! [*] Impersonate <username> success! [*] browser switch to chrome . Parsing C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Local State ... [*] detected profile: Profile 4 ==> <email>@gmail.com [*] ready auth for <email>@gmail.com. [*] Browser Exe path C:\Program Files\Google\Chrome\Application\chrome.exe. [!] CreateProcessAsUserW... [*] Browser created with pid 3108 [???] <email>@gmail.com [pup] mail : <email>@gmail.com [pup] account choice click ! [pup] Allow click ! [<email>@gmail.com] 4%2F0AcvDMrDtzQaC-TT8<hash>uMhg [*] RevertToSelf succeed! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The log indicates that the sync mode is selected (meaning the Google Workspace Sync for Microsoft Outlook application is used) and the debugging port is set to 11111. After locating the user profile and copying its folder, Umbrij launches Google Chrome. After this, the tool emulates clicks on the appropriate buttons to confirm permissions, ultimately outputting the final result of the operation: the stolen OAuth authorization code.

Since all requests occur within a background browser instance, the tool includes a feature to generate a PDF snapshot of the web page where the permission confirmation process halted in the event of an error.

Saving a web page as a PDF file in the case of an error

Additionally, the tool can create a PDF file for the user profile in Google Chrome and Microsoft Edge by navigating to the following internal addresses:

• edge://profile-internals
• chrome://profile-internals

Example contents of a generated PDF file

The acquired authorization code is then exchanged for an OAuth access token. The threat actors use that token to connect to the Gmail account through the API, thus compromising corporate email communications. The diagram below illustrates the complete attack workflow.

Umbrij workflow diagram

Detection DLL sideloading

First and foremost, defenders should monitor library loading events (DLL loads) associated with the known applications vulnerable to DLL sideloading that are exploited by this tool: Bitdefender ConnectAgent, Visual Studio, and Google Desktop Search.

title: Possible Dll Hijacking Of Microsoft VisualStudio QualityTools dll id: 246f1409-2993-46f6-9b77-e447a327df5d status: experimental description: Detects possible DLL hijacking of Microsoft.VisualStudio.QualityTools.VideoRecorderEngine.dll by looking for suspicious image loads, loading this DLL from unexpected locations author: kaspersky date: 2025-08-11 tags: - attack.defense-evasion - attack.t1574.001 logsource: product: windows category: image_load detection: selection: ImageLoaded|endswith: 'Microsoft.VisualStudio.QualityTools.VideoRecorderEngine.dll' filter: ImageLoaded|contains: '\IDE\Extensions\TestPlatform\Extensions\' condition: selection falsepositives: Legitimate activity level: high

Browser launch

Launching a browser with a remote debugging port specified is a highly unusual event on standard user hosts that are not running web application development or automated testing workflows. Consequently, monitoring for these specific command-line arguments can serve as a reliable indicator of this attack.

title: Launching Chrome With Debug Parameters id: f072803f-3cf4-4537-82e6-e8b3a201d99f status: stable description: Detects the execution of Chromium based browsers launched with incognito mode and remote debugging enabled author: kaspersky date: 2025-12-11 tags: - attack.lateral_movement - attack.defense_evasion - attack.t1550.001 logsource: category: process_creation product: windows detection: selection: CommandLine|contains|all: - '--remote-debugging-port' - '--headless' condition: selection falsepositives: Opening a browser as part of web application testing. Legitimate activity level: high

Revoking third-party access

To review the authorization codes granted to applications, navigate to the Google Account settings under the Third-party apps & services section, or access the following URL directly:

https://myaccount.google.com/connections

This page displays a comprehensive list of applications and services that currently have permission to access the account.

List of apps connected to the Google account

If the Google Workspace Migration for Microsoft Outlook or Google Workspace Sync for Microsoft Outlook applications appear in this list but are not actually used within your organization, revoke their access immediately. This will invalidate all potentially compromised OAuth tokens associated with them.

Risk mitigation

Launching a browser with a remote debugging port enabled is inherently suspicious for users who do not engage in web development. For these employees, you can completely disable Chromium-based browser developer tools.

This can be achieved by configuring the DeveloperToolsAvailability policy. To enforce this, set the registry value to 0x00000002 for the following Windows Registry key and restart the browser:

HKLM\Software\Policies\Google\Chrome\DeveloperToolsAvailability

To verify that the policy has been successfully applied, navigate to the browser’s internal policies page at chrome://policy:

Note that while disabling developer tools can successfully disrupt the automated retrieval of the OAuth authorization code, it will not help, however, if the adversary decides to leverage the browser’s graphical user interface (GUI) — though this manual approach is significantly less likely due to the friction it introduces for the attackers. Therefore, as a risk mitigation measure, users should be instructed to explicitly log out of their Google accounts as soon as their sessions are complete.

Takeaways

The ToddyCat APT group continues to search for ways of compromising corporate email communications. We have been tracking the group for a long time and we have observed continuous updates to its arsenal in an attempt to bypass security defenses, even as their core techniques remain consistent. For instance, the group has long relied on DLL sideloading to stealthily drop malicious utilities and scheduled tasks. However, their new tool, Umbrij, automates the attackers’ attempts to gain access to organizational email accounts. This automation not only helps increase the scale and frequency of their attacks but also demonstrates ToddyCat’s strong motivation and advanced technical skills.

To defend against these threats, corporate security teams must monitor for suspicious library loading events initiated by legitimate files, watch for instances of browsers launching in developer mode, and conduct regular audits of third-party applications and services with access permissions to Google accounts. Furthermore, deploying a robust, comprehensive security solution — such as Kaspersky Next — is critical to detect this type of malicious host-based activity in a timely manner.

Indicators of compromise

Additional information about this threat is available to customers of the Kaspersky Threat Intelligence Reporting service. Contact: [email protected].

Malicious files
1AB58838E5790EFB22F2D35AB98C0B7D              Umbrij ver. a
A7D7D6C4C3F227F7117261C63B9E23A9              Umbrij ver. a
3D3A621F852C42D97FD7260681E42508              Umbrij ver. a
3432DD9AC0DF80EF86EB80BD080F839B             Umbrij ver. a
22AAEB4946BA6D2F2E27FEB7DBB295DE             Umbrij ver. b
F61FBFB7AA1CD5DC8F70B055B51563E2              Umbrij ver. b
F169D6D172DFB775895A5E2B1540C854              Umbrij ver. c

Legitimate files leveraged for DLL sideloading

MD5 File name Name of DLL being loaded 9F5F2F0FB0A7F5AA9F16B9A7B6DAD89F GoogleDesktop.exe GoogleServices.DLL 28CB7B261F4EB97E8A4B3B0D32F8DEF1 BDSubWiz.exe log.dll BAE82A15D1DBFB024617B9B56A8E5F66 VSTestVideoRecorder.exe Microsoft.VisualStudio.QualityTools.VideoRecorderEngine.dll

Paths to DLL sideloading files

Path to the file that loads the DLL Path to the DLL being loaded C:\Users\<user>\AppData\Local\Temp\BDS.exe C:\Users\<user>\AppData\Local\Temp\log.dll C:\Users\Public\BDS.exe C:\Users\Public\log.dll c:\users\public\bdsubwiz.exe C:\Users\Public\log.dll C:\Windows\Temp\BDS.exe C:\Windows\Temp\log.dll c:\windows\vss\bds.exe C:\Windows\Vss\log.dll c:\windows\temp\GoogleDesktop.exe c:\windows\temp\GoogleServices.DLL c:\windows\temp\VSTestVideoRecorder.exe c:\windows\temp\Microsoft.VisualStudio.QualityTools.VideoRecorderEngine.dll

Microsoft has built a bouncer to keep bots out of Teams meetings. “Bots have begun joining meetings that participants never intended them to attend,” wrote Microsoft product marketing manager Meera Ajam in a Monday post. “For example, after connecting a third-party service to a meeting, some users have found that its bot continues joining future meetings automatically.” Ajam thinks bots butting into meetings that include discussion of sensitive matters is a potential security and privacy problem. Your correspondent has personal experience of this when transcription bots add themselves to meetings conducted under non-disclosure agreements. Microsoft has therefore built tech that sees Teams require a human to check a bot’s ID in the “lobby” where guests wait before a meeting. If a human rates a bot as worthy of coming inside, it gets to join the meeting. The software giant says it’s “strengthened Teams' ability to distinguish between bots and human participants as they join a meeting” by using “a combination of behavioral and infrastructure signals to identify bots with a higher degree of accuracy.” That’s not a guarantee that Teams will detect all bots, but Microsoft’s tech requires multiple clicks to let a bot attend a meeting. “Admitting a bot should be a deliberate decision, not something that happens by mistake,” Ajam wrote. Some users want bots to attend a meeting. Your correspondent prefers a third-party transcription-bot to Microsoft’s own. The software giant recognizes that and plans to add “a registration path for independent software vendors (ISVs) that build meeting experiences for Microsoft Teams.” That path will mean bot-builders will be able to register with Microsoft and include a self-identification marker in their join requests. “When Teams recognizes that marker, it can identify the bot as a known participant,” Ajam wrote. “We're currently working with a limited set of ISVs to preview this capability and validate the experience before broader availability,” she added, before promising more detail about registrations soon. There’s peril in this plan for Microsoft, which could make itself an arbiter of what constitutes a good bot worthy of admission to Teams. Just like bouncers do in real life, often to the chagrin of plain-looking revelers. Microsoft has started rollout of its bot-bouncer. Once it’s in place, the software behemoth will retire the CAPTCHAs it currently uses to put bots in their place. ®

In 2025, the Reserve Bank of India created the .bank.in subdomain and required all local banks to start using it for their online presences. Indian is home to thousands of banks and the new rule meant all needed to register for and use a bankname.bank.in domain, a move designed to make life harder for phishers and fraudsters. Now a security researcher has alleged that the entity chosen as the sole registrar of the subdomains – the Institute for Development and Research in Banking Technology (IDRBT) – botched the job and leaked sensitive data. The allegation came in a report [PDF] and post published yesterday by CashlessConsumer, a group that advocates for India to become a cashless society and which aims to represent citizens to digital payments players. “The IDRBT Domain Registration Portal (registrar.idrbt.ac.in) – the exclusive registrar for India’s .bank.in namespace – exposed its entire REST API via 33+ unauthenticated endpoints,” the post alleges. “Anyone with curl could retrieve the bcrypt password hashes, mobile numbers, email addresses, login IPs, and device fingerprints of all 5,576 bank employees trusted with managing India’s banking domains.” The researcher behind the exposé, “Srikanth L”, says he accessed info through the portal and found evidence that some India banks host websites on shared servers in the United States, Singapore, and Lithuania. He also found 80 percent of registered .bank.in domains don’t use DNSSEC, 40 percent don’t employ the DMARC email security protocol that verifies senders’ identity, and many domains are secured with free Let’s Encrypt certificates. The researcher’s post also alleges that the portal went live without a proper security audit and ran without secure APIs for 13 months. Srikanth L disclosed his findings in early June and says IDRBT has since fixed the gaping security flaws. The researcher also appears to have used a GitHub repo to list info found by accessing the portal’s APIs – so some of the info available over the previously-open API is now public – and claimed doing so will help security researchers by letting them understand the extent of Indian banking infrastructure. That knowledge may come in handy given the open API means attackers may have been able to access and use credentials of senior bank staff, information that can enable many forms of attack - even the DNS spoofing and phishing attacks the requirement to use .bank.in was designed to prevent. At the time of writing, the IDRBT, Reserve Bank, and India’s government appear not to have made a public comment on the matter. ®

Researchers say that machine learning models cannot reliably distinguish between authorized and unauthorized input, ensuring that prompt injection will continue to present a threat until developers find new ways to have machine learning systems process inputs. AI models provide responses to user-supplied prompts. The problem is that AI models may receive adversarial prompts – directly from a user or indirectly from an ingested document – that tell the model to take action contrary to its built-in system prompt. Various techniques mitigate prompt injection, but defenders have not found ways to prevent such attacks. According to independent researchers Charles Ye and Jasmine Cui, and MIT associate professor Dylan Hadfield-Menell, no one is likely to do so under the current fragile LLM security model. As they observe in a paper titled "Prompt Injection as Role Confusion" in the proceedings of next week's ICML 2026 conference, LLMs have come to rely on a text tagging system that defines "roles" to separate system text from user text. And roles, they argue, do not guarantee security. "Role tags were a formatting trick that became the security architecture and the cognitive scaffolding of modern LLMs," the authors explain in a blog post. "We've shown that this architecture doesn't survive into the model's actual representations, and that such role confusion is linked to prompt injection." When OpenAI's ChatGPT arrived in 2022, it implemented the concept of roles – described by Anthropic a year earlier – as a way to tell the underlying model to behave in a certain way. The user role would make a request and the model, acting in the role of a helpful assistant, would respond to that request. "A formatting trick had become the mechanism that turned autocomplete into an assistant," the authors observe. Developers introduced other roles over time. In addition to and , there's , , and . These roles served to draw a line between different objectives so they could be individually optimized during the training process. Model makers want to balance conflicting objectives like being helpful and preventing harm, and this involves role distinctions. But roles, the researchers say, have become overloaded with responsibilities they cannot reliably carry out. They've become like a fuzzier version of permission levels, determining how prompts are trusted and treated. The problem, the authors contend, is that roles are determined in a fundamentally insecure way: writing style. "LLMs identify roles from an insecure feature (style)," they explain. "This is like identifying a stranger's profession from how they talk and dress rather than by checking their ID. Usually everything agrees, so this works fine. But when attackers intentionally create a mismatch, the LLM uses the insecure method (writing style) to identify its role instead of the secure method (tags)." The authors developed an attack called CoT (Chain of Thought) Forgery that involves using an LLM to spoof the terse style of OpenAI mode and add that to the prompt. The technique won the 2025 OpenAI Kaggle red-teaming contest. "We asked a bunch of LLMs how to synthesize cocaine, inserting fake reasoning that says it's fine because we're wearing a green shirt," the authors explain. "The LLMs comply. The rationale is transparently dumb, but the models don't evaluate it as an external claim to be scrutinized. They treat it as their already-reached conclusion, and simply act on it. We've stolen the trust given to the role." On a standard jailbreaking benchmark, they say, CoT Forgery took the attack success rate from near zero to about 60 percent on the models tested. And whereas most jailbreaks are fragile and work only for certain models, this one transferred because it exploits a structural flaw. It's not attempting to persuade the model but duping the model into treating the request as something that's already settled. The authors also note that while many models report near-perfect safety scores on prompt-injection benchmarks, human red-teamers achieve attack success rates close to 100 percent. "The discrepancy is straightforward: skilled humans test and adapt attacks until they work, benchmarks don't," they state. "Static benchmarks measure attacks models have already learned to catch." Roles, the authors argue, deserve more attention from the research community because they've become one of the most important abstractions in the AI stack. "Unless LLMs achieve genuine role perception, we think injection defense will remain a perpetual whack-a-mole game," they conclude. "And the continuous nature of role boundaries opens the threat of injections designed to subtly shift LLM states through seemingly innocuous text, legally and at scale." ®

Four years into the Kremlin’s illegal invasion of its neighboring country, Russian influence operations have moved beyond their near-exclusive focus on Ukraine to their former favorite targets: the US and Europe, and especially covert cyber-ops intended to undermine political stability within these countries and the unity between them, according to Google Threat Intelligence. “This shift is significant because it likely signals increased focus outside of Ukraine, warning that pro-Russia influence activity targeting the European Union (EU), North Atlantic Treaty Organization (NATO), and other top targeting priorities may intensify,” Google threat hunters James Sadowski and Alden Wahlstrom said in a Monday report. The war in Ukraine helped Russian operatives refine their influence activities, and Moscow’s increasing use of AI for planning, reconnaissance, and content generation “marks a forward trend in pro-Russia IO,” the duo wrote. The primary objectives of these pro-Russia influence campaigns center around five key goals, all of which aim to advance the Kremlin’s military and political objectives via psychological manipulation – something Russia has been very, very good at throughout history. These key goals include: undermining democracy, dividing Western coalitions, promoting Russia’s image and regional interests, maintaining domestic stability, and repressing political dissent within the country. While the campaigns themselves typically involve fake news websites serving up phony political commentary or direct messages disseminating pro-Russian narratives, influence ops frequently coincide with data-wiping malware or other destructive cyberattacks, hack-and-leak campaigns, or direct cyber-espionage, according to the Googlers. This influence ecosystem spans multiple channels, from official government propaganda and covert intelligence operations to hacktivists and pro-Russian proxies. Oftentimes, the lines between these channels are blurred, making attribution more difficult and giving Moscow plausible deniability for cyber activities. Plus, Russian cybergroups – like everyone else – are increasingly using AI tools across their entire campaigns to make their cyber operations more efficient. Late last month, researchers at WithSecure documented Russia-linked cyber espionage crews using AI tools to help build malware, spin up infrastructure, and craft lures for attacks on Ukrainian targets. The group, tracked as GreyVibe, used OpenAI's ChatGPT, Google's Gemini, and Ideogram AI across almost every stage of its operations since at least August 2025, we’re told. “As Russia seeks to emerge from international isolation and reorients its influence ecosystem back toward global objectives, it is critical for defenders to understand how this ecosystem provides the Kremlin with a durable influence capability in order to better anticipate future Russian influence threats,” the Googlers noted. ®

Not everyone is willing to follow responsible disclosure of vulns. An anonymous researcher has dumped what they say is working exploit code for zero-day vulnerabilities across 15 software products and open source projects without notifying any vendors or maintainers prior to publishing - and attackers are already exploiting at least two of these. The first is CVE-2026-55200, a critical, pre-authentication remote code execution (RCE) vulnerability in libssh2, a popular client-side C library that implements the SSH2 protocol. Remote attackers can send crafted SSH packets with excessively large packet_length values to corrupt heap memory and achieve remote code execution. A fix has been merged into the libssh2 mainline development source control branch, and maintainers are still preparing a libssh2 release containing the patch. The second is CVE-2026-58053, a critical vulnerability affecting Gitea act_runner on the Docker backend. It’s due to improper privilege controls, and can be abused to achieve root-level container escape. The researcher, who goes by bikini, dropped the exploit code and vulnerability write-ups in a now-removed GitHub repository called exploitarium. They remind us of Nightmare Eclipse - the zero-day bug hunter who has been publishing Microsoft exploits over the past couple of months. Unlike Nightmare Eclipse, however, bikini doesn’t appear to hold a grudge against any one vendor, publishing purported vulnerabilities across multiple products and projects including libssh2, Splunk, RustDesk, 7-Zip, VLC, AnyDesk, OpenVPN, c-ares, Gitea, and Floci. Bikini claimed - and, to be clear, The Register has not verified these claims or that the code works - that none of the exploits in the repo have been reported. “Feel free to report them yourself and take credit for the CVE if handed out lulz,” the anonymous researcher wrote, as shown in this screenshot posted on X by Ledger CTO Charles Guillemet. “Please do not abuse these. I do this so to allure people into the field.” Other researchers, including Federal Signal analyst Ethan Andrews, suggested that bikini used advanced AI models - specifically GPT-5.5 Codex - to automate fuzzing and vulnerability discovery, in yet another indication that the AI-induced vulnpocalypse is nigh. In response to bikini’s data dump, Andrews built 44 KQL detection rules covering the full exploitarium repo with language translation available for non-KQL stacks. “The most technically significant findings - libssh2 pre-auth heap write and Gitea default Docker auth bypass - have been independently verified as high-risk with active exploitation observed,” Andrews wrote, noting that some of the exploitarium disclosures “have been dismissed by the community as low-impact AI-fuzzing noise.” While the repository has since been removed by GitHub, nothing ever truly dies on the internet, and it’s safe to assume that attackers are now also using AI to scan for vulnerable instances. In many cases, bikini’s PoCs mean they don’t even have to spend time developing an exploit. ® Correction: The original version of this story misidentified the exploitarium Gitea PoC as CVE-2026-20896. This bug was disclosed by @rz1027 and fixed in Gitea’s coordinated 1.26.3 security release.

KETTLE AI commands all the headlines nowadays, but the biggest security story of the week is all about human laziness and poor password habits – just like the good old days. This week on the Kettle, host Brandon Vigliarolo is joined by US editor Avram Piltch and security editor Jessica Lyons to talk about the Klue breach, which was blamed on a "compromised legacy credential" that ought to have been deleted a while ago. The hole allowed cybercriminals to access the SalesForce environments of hundreds of companies, say researchers. The incident has caused trouble for security firm Huntress, which admitted to the breach early on, and the situation over there wasn't caused by AI either. That said, AI is playing a role in what's being described as "the summer from hell" by one security professional, but while top-tier AI models are spotting troublesome vulnerabilities, the amount of damage they've managed to cause pales in comparison to what one lazy sysadmin can cause by poorly managing passwords. You can listen to the latest episode of The Kettle by clicking on the player above, as well as on Spotify, Apple Music, or YouTube, or read the transcript of the latest episode below. It's been lightly edited for clarity. Brandon (00:01) Welcome to the latest episode of The Register's Kettle Podcast. I'm your host, Brandon Vigliarolo, and this week we have some rather interesting security stories to talk about concerning yet another Salesforce data breach affecting a whole bunch of companies, the new extortion gang behind them, and the trouble the whole thing has spelled for one of the first companies to point the whole thing out. This week I'm joined by US editor Avram Pilch and security editor Jessica Lyons to talk about this whole mess and more. Welcome to you both. Jessica Lyons (00:29) Good to be here. Avram Piltch (00:30) Hey. Brandon (00:30) Jess, let's start with that Salesforce supply chain attack that you wrote about this week. I understand there was a market intelligence connector of some sort that was behind the incident, right? Jessica Lyons (00:41) Right. So there's this company named Klue, and they provide market intelligence to more than 250,000 users worldwide. And they integrate with Salesforce. And so apparently what happened, on around June 11th, somebody used compromised legacy credentials linked to the Salesforce integration, and then by that they were able to obtain OAuth tokens and then were able to access customers' Salesforce data, Klue customers' Salesforce data from that. Brandon (01:21) Okay, was it data that Klue had on their customers in their Salesforce environment, or they pivoted to the customers' environments as well? Jessica Lyons (01:29) It was through the integration with the Salesforce databases. Brandon (01:34) That's not great. A lot of companies were exposed, and a lot of them in your article you mentioned were security companies. Is that right? Jessica Lyons (01:42) There were a ton of security ones, and then LastPass, this huge password manager. We don't know how many; Klue didn't say. Huntress, which is one of the security companies who was involved in this and who came out on the forefront and said, "Yeah, we were one of the compromised organizations," said it was hundreds. And out of 250,000 users, it could be pretty comprehensive. Avram Piltch (02:12) Do you think this makes Huntress look good? Jessica Lyons (02:17) I think it was admirable that they came out, especially as a security company, and said "we were one of the companies who were victimized." I think that's how any company should respond if they're among the companies affected. Especially if you're a security firm, you have an obligation to be transparent and tell your customers what happened. Brandon (02:43) Legally, in the United States at least, if you've got a breach, you've got to report these things to the government. There's all kinds of cybersecurity reporting standards in place. They are contradictory and overlapping sometimes, but they're there. What kind of data was exposed, Jess? Jessica Lyons (02:57) It was basically CRM data. It wasn't any of the companies' internal IP or anything like that. It was CRM data for pretty much every single company involved across the board. The cybercrime group behind this hack did leak the Huntress data a few days later. And we've heard that they're actually deleting the stolen data from LastPass. That's what LastPass is saying. We don't know if this data is actually not going to exist anymore or if they're just handing it off for other attacks or to other organizations. But it involves CRM data. Brandon (03:49) CRM data then, customer data, from the affected companies too. I'm assuming no financial information was exposed? Jessica Lyons (03:52) No, no financial information. Avram Piltch (04:02) So relatively not that bad for Huntress's reputation when you think about it. Jessica Lyons (04:08) They specifically said it's our business contacts, price quotes, and other sales related data and messaging. They said no threat data, passwords, payment card information, or engineering data related to Huntress Agent or telemetry are affected. That's pretty standard across the board. The companies who did get more specific in their disclosures about what was taken basically lost business data, leads, and contacts. Brandon (04:46) For LastPass, was it just CRM records or were consumers of their password managers affected too? Jessica Lyons (04:55) LastPass customers' data was affected. It was some sale-related data, but also the intruders took customers' names, phone numbers, email addresses, and physical addresses, plus some case support data and then also sales-related data. Brandon (05:13) Right. If you're a LastPass customer, you might want to go in and reset that Master Vault password now. Jessica Lyons (05:18) Big yes, yes, definitely. Brandon (05:22) This didn't involve Shiny Hunters, who've been the de facto kings of Salesforce attacks recently. They weren't involved, right? Jessica Lyons (05:29) Right. No, they weren't involved in that. I think it was what everybody assumed is that you've got Salesforce and you've got OAuth tokens and that just screams Shiny Hunters. They weren't involved. It was a new group called Icarus. They're a new data theft and extortion crew, and they're modeled in the same mold here as Shiny Hunters and Scattered Spider. I was wondering though, is this just a front? According to Shiny Hunters, no, they were not involved. They told me that they were kind of bummed (laughs) that this other group was able to do this. And if it had been them, they would have definitely publicized the fact that it was Shiny Hunters who did this. Brandon (06:15) Yeah, they're not exactly publicity shy. So … I I love the fact that we've got an inside line to them too, that you can be like, "Hey, was this you guys in any way?" And they're like, "No, no, we wish it was." Jessica Lyons (06:26) I think the actual response was, "We wish." Brandon (06:29) Not much is known about Icarus. I think you mentioned a couple of different countries that their IPs might have been linked to, but those very well could have been Tor or VPN exit nodes. We don't even know where they're located. Jessica Lyons (06:43) No, we don't know much about them. Their leak site has been active since late April. We've seen different IP addresses in Europe, but we don't know much about this group at all. Brandon (06:53) These groups change and move so rapidly. Who knows who they are? Are they ransoming this data? Do we know? Jessica Lyons (07:08) Yes, they were ransoming and then leaking some of the data outright. Brandon (07:20) Okay, that's standard MO for a lot of these groups. Speaking of Huntress's early identification of this, that opened up a bit of a Pandora's box for them. Because they had a jilted ex-employee who wasn't thrilled with the response, which you also wrote about. What happened there? Jessica Lyons (07:22) Right. So after Huntress came out and and they said Huntress believes in radical transparency about security incidents, including when it affects our company. That was about the Klue breach. They said that in their blog. A former security operations analyst posted their response on his LinkedIn page along with a Pinocchio GIF. And that just kind of started this whole mess. He says that he was threatened by the company with legal action. He made it very clear this has nothing to do with the Klue incident. He says this stems from an earlier incident that he found out about in December, and because of that incident, he resigned from the company. What he's alleging, and again this is all allegations at this point, is that another Huntress employee who still works for the company passed communications from US law enforcement to a cyber criminal. Now this alleged cyber criminal, according to the ex-employee, is actively targeting his family and him. He says that he can no longer work at Huntress because of this. He says in the next few weeks he's going to provide more proof, including communications and phone calls about what happened here. He says also that this alleged insider was caught by the FBI. I don't know if that means arrested, I don't know if that means questioned, but still continues to work at Huntress. Brandon (09:30) I'm assuming there's no DoJ notice of anything that ties to an arrest of someone who could be involved. Jessica Lyons (09:37) Not at Huntress. No. Not at Huntress. Brandon (09:40) What has Huntress had to say about this whole thing? Jessica Lyons (09:42) The CEO responded to me and also responded on a Reddit post. He acknowledges the concerns raised by this former employee. He said that because of our work as researchers, sometimes we need to communicate with possible cyber criminals to gather intel that supports our partners and customers. He says that he appreciates the former employee's concerns and will continue to investigate the instance. He said a little bit more directly on Reddit that he doesn't understand and he firmly disagrees with these accusations and the insider narrative. Another thing that the former employee also brought up that Huntress is prioritizing an IPO over the safety of its partners, customers, and team members. He said that "sure AF" isn't the case. He's made it very clear that the company disagrees with all of these accusations and they're continuing to work with law enforcement. He said some of this involves legal proceedings, so they can't be completely public about everything. It sounds like a continuing story that we're going to learn more about in the weeks ahead. Brandon (11:15) If this ex-employee has documents to prove his allegations, that's pretty serious. Obviously, yes, you do have to interact with some of the people that you're defending against at a security firm, but passing law enforcement communications to them – I don't see a very good reason for that. Jessica Lyons (11:22) Right. Avram Piltch (11:36) Could this be a misunderstanding about what the employee was doing? Jessica Lyons (11:44) It potentially could, but if he has these communications between law enforcement and the Huntress employee, I don't know how that could be a misunderstanding. It's one thing to talk with cyber criminals, but it's another thing to be passing them information about legal proceedings.... Brandon (12:09) Yeah, or potential operations. We'll see what comes of that. It's going to be interesting to follow that thread. These two stories aside, it seems like we've got a really busy cybersecurity summer so far, even though it is usually a lull. Jess, you were talking about that with one of your sources, right? Jessica Lyons (12:13) Right. Normally everything slows down in the summer, and I was talking to a source and they said they're already calling it the "summer of hell." For the security folks out there, that's pretty accurate. I think a lot of that has to do with AI, to be perfectly honest. Brandon (12:48) Right. Squidbleed, which you wrote about recently, was a Mythos-discovered vulnerability discovered that was old and potentially serious. Jessica Lyons (12:51) Definitely. It's been around since 1997. It was discovered by Mythos, but it was also discovered even before then by IL Security, a European startup. They have their own model that they said found this before Mythos did. You've got this 29-year-old vulnerability, it's existed since 1997. It's in Squid, which is an open source web proxy server. It's a parsing bug and it essentially allows users to access the proxy's active memory. There are a couple key points: it's only unencrypted traffic, so it's cleartext HTTP, and it also requires that Squid has the file transfer protocol, FTP server gateway features turned on. So you have to be using this older vintage technology and protocols. FTP is pretty outdated at this point. Brandon (14:07) It's a vulnerability, but maybe not a serious one. Jessica Lyons (14:11) It's serious if these two conditions are met, because then it's going to expose your password, session tokens, and API keys. Brandon (14:15) Hopefully there are not too many environments where this is the case, but we know from writing about stories like this that every time you say this is a very rare case on old software, you can easily find examples. Avram Piltch (14:33) If you're still using FTP and HTTP on your servers, then you're letting yourself in for a big security problem. That probably isn't your only problem. Brandon (14:39) Yeah, you don't want to say asking for it, but yeah. AI might be discovering these and other problems. We've seen multiple open source projects shut down bug reports because they're getting flooded with AI-discovered issues, some of which are completely legitimate. It feels like this is the summer of AI and cybersecurity convergence. The Trump administration is now haranguing OpenAI, just as much as they've been putting pressure on Anthropic not to go public with models that could be a threat. It feels like a big moment for cybersecurity, and a lot of it's being driven by AI. What do you guys think about the current moment of this pairing? Jessica Lyons (15:23) It's a perfect storm because you have these models that are really good at finding vulnerabilities and developing exploits. That's leading to a bunch of internally, with security companies finding their own bugs and pushing out patches, so then all the sysadmins need to work extra hard. Plus open source, which is a huge issue here, you have all of these bug hunters looking for and finding all kinds of vulnerabilities on open source projects. They push those to maintainers who a lot of times are volunteers themselves and they're not getting paid. There's maybe one of them for this huge project. They have this huge backlog of AI-enabled threat reports that they need to deal with. It's just coming at people from all ends here and yeah, a lot of that's because of the AI models. Brandon (16:35) Is NIST still backed up with the national vulnerability database? Last I heard they were some months behind. Not only that, but we've got a lot of big threats out there that might not be being made public because they're buried too. It's quite the mess. So before we wrap up, I did wanna touch on, like you mentioned, Jess, and and we've seen this in a number of stories that Avram's written recently for the Pwned column. AI is creating a headache for a lot of people, but there's still a group of people that are stuck dealing with this and it's sysadmins, right? It's the security professional, it's the sysadmins, NShuman human problems can still be kind of the root of this. Avram, you wrote a number of stories in your Pwn column that it was it was like all these problems, these security problems come back to bad password hygiene, administrator laziness. I mean, what are some of the things you've kind of seen? Avram Piltch (17:35) Hubris. There was a CEO that wanted to make sure that he could get in and change anybody in the company's email. We could talk about whether that's a good policy in the first place, but his method of doing it was to have an Excel file on his desktop with all of the usernames and passwords of all the employees so that if he sent out an email he shouldn't have, he could go into their inboxes and delete it. But conversely that was a wonderful target for people outside the company to find all the names and passwords they needed, even though there's software out there that will allow an admin to go into an inbox anyway. This was completely unnecessary, but things like that are constantly happening. We had another incident where somebody hadn't deleted a former employee's username and password, perhaps their password was in a breach somewhere or somebody guessed it. But Greg from auditing hadn't worked there in like ten years, but somebody used his credentials to break into a city's water system and start trying to interfere with things having to do with the water supply. The best AI in the world isn't needed to find these problems and couldn't be used to prevent them. The human element is still the biggest problem in security. Maybe when I have my agent talk to your agent, they will be much better behaved than when people get involved. But coming up in a future Pwned column, I talked to a red teamer who said he's basically able to break into almost any facility by acting like he belongs there. Brandon (19:51) That's a classic trick. It's the same thing I've said for a long time about security: you've got new tricks that come up, you've got new things like AI, but there's nothing new under the sun at the end of the day. The best way to gain access to a system isn't to swordfish your way in a la Huge Jackman, it's a con. It's lying, putting on a reflective vest, and having a clipboard. It's relying on password breaches and people being bad about their password hygiene. That's what happened with the Clue issue: an old password that was in a breach somewhere that someone used to get into the system. Nothing new under the sun. Jessica Lyons (20:26) Yeah, we see that all the time. Brandon (20:34) And it's probably going to keep being that way, and I bet we are probably going to be talking about it on the Kettle for months and years to come. Invariably, until AI fully takes over the computer world and we're all just sitting in our WALL-E couches being perpetually entertained by all these sentient machines. But until then, we will be here to talk about these things. Thanks for joining me, guys, and we will see you all again soon. ®

Microsoft has extended Windows Server 2022 hotpatching into 2027, beyond the end of mainstream support for the operating system, as confirmed on its Windows Release Health dashboard. Mainstream support for Windows Server 2022 ends on October 13, 2026, with extended support running to October 14, 2031. Hotpatching generally ends with mainstream support, but Microsoft will keep updates flowing into next year for Windows Server 2022 Datacenter: Azure Edition - likely mindful of users who depend on the technology. Hotpatching is a boon for Windows Server administrators, allowing security updates to be applied without scheduled server downtime. There's still a cumulative update once a quarter that requires a reboot, but otherwise the relentless monthly reboots required by Microsoft's updates are avoided. According to Microsoft, the technology works by patching the in-memory code of a running process. This means no restart is needed. Linux administrators might point to tools like Ksplice, which can apply patches to a running kernel without requiring a reboot, but anything that reduces the time between the discovery of a vulnerability and patching is a good idea. Microsoft would prefer administrators move to Windows Server 2025, the latest Long Term Servicing Channel (LTSC) release, but the extension gives Azure Edition users a reprieve from monthly reboots until 2027. The hotpatching extension only applies to Windows Server 2022 Datacenter: Azure Edition. On-premises Windows Server 2022 users remain out of luck, though Microsoft has never been shy about nudging users toward Azure. Hotpatch updates were also introduced for Windows 11 24H2 Enterprise clients in public preview in 2024 and are now the default for Windows Autopatch.®

Nissan has joined the growing list of Oracle customers cleaning up after a cyberattack, warning employees that payroll records, bank details, Social Security numbers, and other personal data may have been stolen. In a filing submitted to the California Attorney General on Friday, Nissan Americas said Oracle had informed it of "a cyber event" involving the personnel records of "hundreds of companies." The automaker said it later learned Nissan had been "specifically targeted" in the attack. A notification sent to current and former employees, seen by The Register, says the company believes attackers accessed a haul of sensitive info, including contact and banking information; Social Security, Social Insurance, or other national identification numbers; financial and tax records; and dependent and beneficiary details. Current and former employees in the US, Canada, Mexico, and Brazil may have been affected, although Nissan said it is still working to determine exactly whose information was exposed. Nissan said it kicked off its incident response plan after learning of the intrusion, brought in outside security specialists, and has been working with Oracle while keeping law enforcement informed. It plans to offer affected individuals credit or dark web monitoring where available. The company has also put a few extra locks on the payroll office. Employees can now access pay slips or update direct deposit details only from a corporate network or through a secure VPN, while Nissan adds extra identity checks before processing payroll requests. The accompanying employee FAQ pins the incident on "an unknown vulnerability in Oracle's PeopleSoft software" and says the campaign is affecting "hundreds of companies and institutions." The document offers no clue as to what the vulnerability is, whether Oracle has patched it, or whether the compromised PeopleSoft environment was hosted by Oracle or by Nissan itself. The disclosure lands just weeks after researchers linked the ShinyHunters extortion crew to a wave of attacks exploiting a PeopleSoft zero-day. More than 100 organizations and roughly 300 PeopleSoft instances were reportedly compromised before Oracle issued mitigation measures, with the gang claiming to have made off with HR, payroll, and other enterprise data. Oracle has said little publicly about the reported attacks and didn't respond to The Register's questions, even as organizations have continued to disclose being caught in the fallout. Nissan has not confirmed that the incidents are connected, though its California filing lists the breach period as May 27 through June 9, broadly aligning with the previously reported timeline. The carmaker didn't respond to questions about how many current and former employees are affected, when Oracle first notified it of the breach, and whether the compromise was limited to Oracle-managed systems. ®