HBO Max’s verified Reddit account hijacked to spread malware

Researchers at Hudson Rock found that cybercriminals hijacked HBO Max’s verified Reddit account and used it to run 108 malicious ads over roughly 48 hours. The ads used HBO Max’s trusted corporate account to promote fake AI tools, developer software, and macOS utilities, lowering potential victims’ guards. Some ads directed users to convincing HBO lookalike sites that claimed to offer a native HBO Max app for macOS or a promotional download. But instead of providing an installer, the sites instructed visitors to open Terminal on their Mac or, on Windows, the Run dialog or PowerShell, and paste in a command. This is the hallmark of a growing social engineering technique known as ClickFix . ClickFix attacks disguise malicious instructions as a routine technical step, such as fixing an error, completing a CAPTCHA, verifying that you are human, or installing software. A web page may silently copy a command to the clipboard , then guide the victim through pasting and running it, by which they will infect their own device. Researchers at ADAMnetworks have dubbed the operation behind the HBO Max ads “PasteSwitch.” Its infrastructure appears to tailor the next stage to the visitor’s device and the lure being used. Observed macOS payloads included MacSync and AMOS infostealers designed to steal browser credentials and profiles, Telegram data, Apple Notes, saved passwords, and cryptocurrency wallet recovery phrases. Windows users could end up with the Amatera infostealer, which runs in memory. The operation has also been linked to cryptocurrency clipboard hijackers, which monitor copied wallet addresses and replace them with an attacker-controlled address before a transaction is sent. How to stay safe Reddit admins paused the ads and opened a security investigation after reports came in, but it is important to remain vigilant. Reportedly , ClickFix was responsible for more than half of all malware loader activity in 2025. One reason for its success is that campaigns continue to add new  methods  for tricking users and different  commands  for avoiding detection. Users of macOS Tahoe 26.4 or later may be  warned when pasting text into Terminal , but it doesn’t appear for everyone, so you shouldn’t rely on that alone. Malwarebytes can provide additional protection at several stages of a ClickFix attack. Browser Guard warns when a website tries to copy something to your clipboard, web protection blocks known malicious sites, and real-time protection can detect malware delivered by the campaign. With ClickFix running rampant and inventing new methods all the time, it’s important to be aware, careful, and protected: Treat ads with caution. A verified account does not guarantee that an ad is safe. Visit the company’s official website directly instead of downloading software through an advertisement. Slow down.  Don’t rush to follow instructions on a webpage or prompt, especially if it asks you to run commands on your device or copy-paste code. Attackers may use countdowns, user counters, or other pressure tactics to make you act quickly. Don’t run commands from untrusted sources.  Never run code or commands copied from websites, emails, ads, or messages unless you trust the source and understand what the command does. Check the instructions against official documentation or contact the company’s support team. Secure your devices.  Use an up-to-date, real-time  anti-malware solution  with a web protection component. Malwarebytes blocks ember-bridge.com, which is part of the PasteSwitch infrastructure. Educate yourself on evolving attack techniques.  Understanding that attacks may come from unexpected vectors and evolve helps maintain vigilance. Keep reading our blog! From reporting threats to removing them. Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by  downloading Malwarebytes today .

The "third-party.com" domain, commonly used as a placeholder in developer documentation and code examples, is serving a fake Cloudflare verification page that attempts to trick Windows users into executing PowerShell commands. The domain third-party.com has long been used in documentation to represent an arbitrary external website, API, or service, similar to how developers use domains such as example.com. However, unlike example.com, example.net, and example.org, which IANA reserves specifically for documentation, third-party.com is a normally registered domain whose content its owner can control. This difference is now a security concern after the domain began serving a ClickFix attack that impersonates a Cloudflare security check. Manifold Security first reported the malicious use of the domain after discovering it while examining public AI skills and MCP server documentation that referenced the domain. BleepingComputer has since confirmed that the page displays a fake Cloudflare "Performing security verification" CAPTCHA screen containing a "Verify you are human" prompt. After the user clicks the verification box, the site copies a malicious PowerShell command into the Windows Clipboard, and then instructs the user to press the Windows key + R, paste the contents of their clipboard using Ctrl+V, and press Enter. When the PowerShell command runs, it reconstructs the payload URL elxxvvx[.]xyz/f, downloads a PowerShell script from that address, and then executes it. This technique is commonly known as ClickFix, where attackers use fake errors, CAPTCHA prompts, or verification pages to convince victims to manually execute commands copied to their clipboard. ClickFix attacks have become a popular way to distribute malware, as the malware is installed via commands executed by the user rather than downloaded from websites or as email attachments. In some cases, this could allow malware to install while bypassing traditional antivirus software. At the time of BleepingComputer's testing, elxxvvx[.]xyz no longer resolved, leaving the current attack chain broken. However, a Hybrid Analysis report from May 2, 2026, shows the site distributed a PowerShell script configured to download a 134MB zip archive from: https://elxxvvx[.]xyz/update2.zip The PowerShell script saved the archive as update26.zip, extracted it, and then attempted to launch an executable named draw.io.exe. Because the update2.zip archive is no longer available, BleepingComputer couldn't determine what the payload does. Manifold's Ax Sharma says the attack specifically targets Windows users, and Linux and Mac visitors will see errors stating their operating system is unsupported. "A macOS or Linux user-agent gets none of that. It gets a near-identical page that stops at an error: "macOS is not supported. This website requires a Windows PC to access." No clipboard poisoning, no payload," explains Sharma. "The attacker only shows the weapon to the targets it works against, which is precisely why a casual look, or a scanner on a Linux datacenter IP, sees nothing wrong." A placeholder that wasn't reserved The more interesting aspect of the attack is the third-party.com domain chosen to host the ClickFix page. Public developer documentation has treated third-party.com as a generic example hostname for many years. For example, the W3C Geolocation specification currently demonstrates granting geolocation permissions to an external iframe using third-party.com as a placeholder domain: The W3C Compute Pressure specification similarly uses the domain when demonstrating how a website can enable the API for remote content: Chromium's documentation for its Telemetry Extension API also uses third-party.com as an example website permitted to communicate with a Chrome extension: Other examples go further and use the domain in code that would actually make network requests if copied literally. A PrivacyCG proposal on GitHub also uses the domain as the destination of a JavaScript fetch() request from a service worker. Posts online indicate that developers have copied these and similar examples into their own code and projects. In a 2015 Stack Overflow question, a developer said they had applied an asynchronous loading example containing https://third-party.com/resource.js to their website before discovering that it did not behave as expected after publishing the site. These examples do not mean that the associated projects or documentation are compromised. However, applications or test code that copied such placeholder URLs could now cause a browser or automated tool to contact the real third-party.com domain and potentially display the ClickFix attack in a browser or application. Unlike example.com, which IANA maintains for documentation and does not allow to be registered or transferred, the third-party.com domain has no such protection, and was clearly hijacked or registered at some point to conduct these ClickFix attacks. "third-party[.]com has been a generic documentation placeholder for years, the same role example.com plays," explains Manifold. "A public code search turns it up in skills, MCP-server docs, and over 1,500 files across 1,700+ repositories from names as trusted as Chromium, Sanity, and Vercel. Since at least June 2026 it's been serving the ClickFix lure." While the widespread use of third-party.com as a placeholder in documentation makes the domain attractive to attackers, there is no evidence that it was registered for malicious purposes. The domain was first registered in 1996, long before the current campaign, and BleepingComputer has not determined when or how control of the site changed. At this time, there have been no reports that these references to third-party.com have actually resulted in ClickFix attacks being executed on developer's devices or within their applications/webpages. However, as the domain remains live, it could easily be switched to a new, live payload domain and actively utilized in future attacks. Join Mikko Hyppönen and security leaders from the NFL, CHANEL, and Atlassian for a two-hour digital summit on what AI-speed attacks change, what defenders should stop doing, and how to validate, decide, fix, and re-validate at machine speed. Save your seat

A domain that has long appeared in software documentation, code examples, and developer test material is now being used to push a ClickFix attack against Windows users. A placeholder domain stands in for a website in an example. The best-known is probably example.com . Another, third-party[.]com , has often been used in documentation to represent an external website, API, or service. However, there is a very important difference between the two: example.com is reserved for documentation, while third-party[.]com is an ordinary domain. Anyone could register it, and someone did. Every document, test, and skill that hardcoded it now points readers and users to the attacker’s infrastructure. Researchers at Manifold Security found that third-party[.]com was serving a fake Cloudflare-style verification page to Windows visitors. The page tries to persuade them to open the Windows Run box and paste a command it has copied to their clipboard.This command is designed to download and execute a PowerShell script. At the time of writing the domain hosting the script is not resolving. ClickFix is a social-engineering technique that turns the victim into the malware installer. Instead of relying on a malicious attachment or an obvious executable download, the attacker convinces someone to run a command themselves. Common lures include: A fake CAPTCHA or Cloudflare Turnstile check. A browser error that claims it needs a “manual fix.” A bogus video-player, document-viewer, or popular software download. A support scam page that tells the visitor to paste a command into Run, Command Prompt, Terminal, or PowerShell. ClickFix works because the command often uses legitimate Windows or Mac tools to download and execute the next stage. It also runs with the permissions of the person who has been convinced to enter it. The consequences can range from information theft to more serious compromise of a company network. In a recent campaign called TerminalFix , a fake Cloudflare CAPTCHA led victims to paste a PowerShell command into Windows Terminal or PowerShell. How to stay safe With ClickFix running rampant—and it doesn’t look like it’s going away anytime soon—it’s important to be aware, careful, and protected. Slow down.  Be wary of a webpage that urges you to run commands on your device, especially if it uses a countdown or other pressure tactic. Don’t run commands or scripts from untrusted sources.  Never run code or commands copied from websites, emails, or messages unless you trust the source and understand the action’s purpose. Verify instructions independently. If a website tells you to execute a command or perform a technical action, check through official documentation or contact support before proceeding. Check what you’re pasting.  A website may copy a command to your clipboard without showing you the full text. Don’t paste it into a command window. Secure your device.  Use an up-to-date, real-time  anti-malware solution  with a web protection component. Educate yourself on evolving attack techniques.  Understanding that attacks may come from unexpected vectors and evolve helps maintain vigilance. Keep reading our blog! Pro tip:  The free  Malwarebytes Browser Guard  extension warns you when a website tries to copy something to your clipboard. Stop threats before they can do any harm. Malwarebytes Browser Guard blocks phishing pages and malicious sites automatically. Free, one click to install. Add it to your browser →

Check Point Research (CPR) conducted a focused analysis of Storm-2603, a threat actor associated with recent ToolShell exploitations, together with other Chinese APT groups. Storm-2603 utilizes a custom malware Command and Control (C2) framework dubbed internally by the attacker as “ak47c2”. This framework includes at least two different types of clients: HTTP-based (dubbed by us “ak47http”) and DNS-based (dubbed by us “ak47dns”). Based on VirusTotal data, Storm-2603 likely targeted some organizations in Latin America throughout the first half of 2025, in parallel to attacking organizations in APAC. Some of the actor’s TTPs align with many other ransomware groups, and involve open-source tools such as PsExec and masscan. In addition, the threat actors use a custom tool that leverages the BYOVD (Bring Your Own Vulnerable Driver) technique to tamper with endpoint protections. Storm-2603 attacks involved multiple ransomware families, sometimes bundled together. Those are commonly deployed by abusing DLL hijacking. Check Point Research (CPR) has been closely monitoring the ongoing exploitation of a group of Microsoft SharePoint Server vulnerabilities collectively referred to as “ToolShell.” These active attacks leverage four vulnerabilities—CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, and CVE-2025-53771—and are attributed to multiple China affiliated threat actors. Among the threat groups identified by Microsoft, two are known APTs: Linen Typhoon (aka APT27) and Violet Typhoon (aka APT31). Another group is a newly observed, previously undocumented cluster called Storm-2603. While Microsoft linked this cluster’s activity to potential ransomware deployment, it was unable to assess the group’s objectives. As part of our ongoing investigation into ToolShell and its associated risks, we launched a targeted effort to better understand and characterize the threat posed by Storm-2603. Throughout our analysis, we uncovered several files likely tied to Storm-2603 intrusions, offering new insights that correspond to Microsoft’s description of the group. In this publication, we provide an in-depth examination of Storm-2603’s tactics, techniques, and procedures (TTPs), along with a technical breakdown of the ak47c2, a custom malware framework used in their attacks and their different ransomware payloads. Storm-2603 was first mentioned by Microsoft during investigations into a set of attacks on Microsoft SharePoint servers, known as the “ToolShell” campaign. While some activity was tied to known Chinese affiliated groups like Linen Typhoon (APT27) and Violet Typhoon (APT31), Storm-2603 appeared as a new, previously unreported actor. Microsoft linked the group to Lockbit and Warlock ransomware use. Figure 1 – Events associated with Storm-2603. Microsoft’s report provided only limited information about Storm-2603, including some of the TTPs associated with it, most of them quite generic. In addition, some of the reported indicators of compromise (IOCs) helped us uncover additional artifacts associated with previous Storm-2603 intrusions. One domain in particular, update.updatemicfosoft[.]com, linked to Storm-2603’s SharePoint exploitation, turned out to have been used in earlier campaigns dating back to March 2025. In those operations, it served as a C2 server for both DNS tunneling malware and an HTTP backdoor and was part of infrastructure used to deliver LockBit Black and Warlock/x2anylock ransomware. Our search for cases where the IOCs reported by Microsoft, revealed two incidents in which LockBit Black and WarLock ransomware variants were deployed together, in addition to multiple other tools, mostly open-source. In April 2025, a RAR archive named Evidencia.rar was uploaded to VirusTotal. The archive contains several artifacts likely extracted from compromised machines in a Storm-2603 case in a LATAM country. The artifacts in the archive provide a look at some of the open-source tools used by the actors in the intrusions which correlates with previous knowledge of the group: WinPcap – Captures and filters network traffic on Windows. PsExec – Executes commands on remote Windows systems. SharpHostInfo – Collects host and domain info on Windows environments. nxc – Exploits common vulnerabilities in network services. In addition to the open-source tools, the archive also contains the custom backdoor used by the group, as well as its unique ransomware payloads. dnsclient.exe – A custom backdoor utilized by Storm-2603 that communicates over DNS tunneling with update.updatemicfosoft[.]com, a domain associated with the group. See the next section for our analysis of the backdoor. 7z.exe & 7z.dll – Legitimate 7z executable side-loading malicious 7z.dll delivering X2anylock (aka Warlock), a ransomware used by Storm-2603. bbb.msi – An installer which uses clink_x86.exe to side-load clink_dll_x86.dll, leading to the execution of LockBit Black ransomware. Another MSI file uploaded to VirusTotal in April used a similar deployment method, starting with the MSI installer to launch multiple ransomware strains simultaneously: Figure 2 – MSI Multi-Ransomware Deployment. The MSI relies on the following files: MpCmdRun.exe & Mpclient.dll – Warlock Ransomware, deployed via DLL-hijacking. clink_x86.exe & clink_dll_x86.dll – LockBit Black ransomware, deployed via DLL-hijacking. z.exe & z.dll – x2anylock ransomware, deployed via DLL-hijacking. VMToolsEng.exe – Custom Antivirus Terminator. ServiceMouse.sys – Vulnerable driver used by VMToolsEng.exe for killing Antivirus processes. log.exe – A list of Antivirus processes to kill. msi.bat – Executes VMToolsEng.exe. 1.bat – Executes all the needed executables and the MSI. We attributed two custom backdoors to Storm-2306, both of which appear to be part of the framework named AK47 C2 based on the shared PDB path: C:\Users\Administrator\Desktop\work\tools\ak47c2\. When executed, the program immediately hides its console window, determines the host computer name (defaulting to unknown.local if that fails), and builds a DNS‑based command‑and‑control payload. It chooses a random five-character session ID, such as H4T14, and prefixes it with 1 for task requests or 2 for result uploads (e.g., 1H4T14 or 2H4T14). Each element, such as the task/result tag, a size flag (a for “all” when the entire message fits into one request), and the computer name, is XOR‑encoded with the ASCII key “VHBD@H”, converted to hexadecimal, and concatenated with dots before being prepended to the C2 domain update.micfosoft[.]com. This what the overall query looks like: DNS TXT and MG (a mail group member record type) record lookups (DnsQuery_A) are used to transmit and retrieve data. If the C2 server is unreachable, the client simply receives error 9003 (DNS_ERROR_RCODE_NAME_ERROR). Otherwise, the response text is decoded from hex, XOR‑decrypted, and parsed for the delimiter “:::”, which separates metadata from the actual command string. Commands run under cmd.exe /c 2>&1; a built‑in directive sleep n pauses execution for n seconds. For outputs larger than 0xFF bytes, the backdoor fragments data into 63‑byte sub‑segments. Each DNS query then follows: HttpClient backdoor has the pdb path C:\Users\Administrator\Desktop\work\tools\ak47c2\httpclient-cpp\x64\Release\httpclient-cpp.pdb and uses plain HTTP instead of DNS for the C2. It is built as a 64‑bit console program that also immediately hides its window on launch. On start‑up, the malware gathers the host computer name (similar to the DNS version, it defaults to unknown.local), then builds a JSON object with the fields cmd, cmd_id, fqdn, result, and type. For a task request, the object looks like this: {"cmd":"","cmd_id":"","fqdn":" ","result":"","type":"task"} After the host executes a command, the result is sent back with type:”result”. Before transmission, the entire JSON blob is XOR‑encrypted with the ASCII key “VHBD@H”, converted to hexadecimal, and placed in the body of an HTTP POST to “/” with generic headers (Content‑Type: text/plain, Accept: */*). The C2 replies with a similarly encoded JSON where the cmd field contains the next command. The implant executes it via cmd.exe /c 2>&1 and returns the output. We identified that during these attacks, several types of ransomware were deployed simultaneously. One is regular LockBit Black, and the second uses the.x2anylock extension. This extension was later used by the Warlock ransomware operator, mentioned in Microsoft’s report on the SharePoint exploitation. The Warlock ransom note is usually saved as How to decrypt my data.txt and looks like this: Figure 3 – Warlock Group ransom note. The ransom notes for all ransomware strains deployed by Storm-2603 are named How to decrypt my data.log (x2anylock) or .README.txt (LockBit Black) and have the same short content: Your decrypt ID: [redacted] Tox ID Support: 3DCE[redacted] Email Support: [redacted]@proton.me,[redacted]@proton.me,[redacted]@proton.me You can contact us in email or qtox. This ransom note’s name How to decrypt my data.log appeared in a recent LinkedIn post by Huntress, describing the case where multiple ransomware families were deployed together against the same target. While not a new tactic, this approach is rarely observed among established ransomware groups. An important part of the infection package described earlier is called Antivirus Terminator. It is a custom command line tool abusing a third-party signed legitimate driver to kill processes. From what we can see, it’s been in the wild since at least late 2024. The tool requires administrative privileges on the infected machine. The screenshot below shows how the listing is displayed in the console when the tool is run without parameters: Figure 4 – Antivirus Terminator supported arguments when run without parameters. The tool first creates a service called ServiceMouse, where the path to the service binary file is ServiceMouse.sys from the package. Next, the tool communicates with the installed service via IO control code 0x99000050, which is responsible for killing processes. The tool also has more capabilities, like deleting files and uninstalling drivers, and these use different IO control codes (0x990000D0 and 0x990001D0). Figure 6 – Antivirus Terminator kills process using third-party driver. The supplied third-party driver is a legitimate and signed component of Antiy System In-Depth Analysis Toolkit, originally named AToolsKrnl64.sys. The toolkit was developed by Antiy Labs, a Chinese security vendor, and features a graphical user interface that allows users, among others, to interact with and manipulate processes. The ability to kill processes is the most important feature which is abused by threat actors in this particular case. Figure 7 – Antiy System In-Depth Analysis Tookit GUI. The following piece of code in the driver handles the IO control code 0x99000050 mentioned above: Figure 8 – IO control code processing in the Antiy driver. The second function is the piece of code responsible for killing a process with a given PID. In this report we analyze Storm-2603, a relatively new threat actor first mentioned by Microsoft during investigations into the “ToolShell” campaign targeting SharePoint servers. While some of the exploitation activity was tied to known Chinese APT groups, Storm-2603 stood out as a previously undocumented group linked to ransomware deployment. By examining infrastructure indicators shared in public reporting, we were able to connect this actor to earlier campaigns involving LockBit Black and Warlock/X2anylock ransomware, dating back to at least March 2025. These earlier attacks used similar infrastructure and tools, including DNS tunneling and HTTP-based backdoors. Interestingly, multiple ransomware variants were deployed in the same attack. This behavior, along with the overlap in techniques, helps us better understand how Storm-2603 operates “The Turkish Rat” Evolved Adwind in a Massive Ongoing Phishing Campaign Check Point Research Publications August 11, 2017 “The Next WannaCry” Vulnerability is Here Check Point Research Publications March 12, 2026 “Handala Hack” – Unveiling Group’s Modus Operandi SUBSCRIBE TO CYBER INTELLIGENCE REPORTS We value your privacy! BFSI uses cookies on this site. We use cookies to enable faster and easier experience for you. By continuing to visit this website you agree to our use of cookies.

On July 19–20, 2025, various security companies and national CERTs published alerts about active exploitation of on-premise SharePoint servers. According to the reports, observed attacks did not require authentication, allowed attackers to gain full control over the infected servers, and were performed using an exploit chain of two vulnerabilities: CVE-2025-49704 and CVE-2025-49706, publicly named “ToolShell”. Additionally, on the same dates, Microsoft released out-of-band security patches for the vulnerabilities CVE-2025-53770 and CVE-2025-53771, aimed at addressing the security bypasses of previously issued fixes for CVE-2025-49704 and CVE-2025-49706. The release of the new, “proper” updates has caused confusion about exactly which vulnerabilities attackers are exploiting and whether they are using zero-day exploits. Kaspersky products proactively detected and blocked malicious activity linked to these attacks, which allowed us to gather statistics about the timeframe and spread of this campaign. Our statistics show that widespread exploitation started on July 18, 2025, and attackers targeted servers across the world in Egypt, Jordan, Russia, Vietnam, and Zambia. Entities across multiple sectors were affected: government, finance, manufacturing, forestry, and agriculture. While analyzing all artifacts related to these attacks, which were detected by our products and public information provided by external researchers, we found a dump of a POST request that was claimed to contain the malicious payload used in these attacks. After performing our own analysis, we were able to confirm that this dump indeed contained the malicious payload detected by our technologies, and that sending this single request to an affected SharePoint installation was enough to execute the malicious payload there. Our analysis of the exploit showed that it did rely on vulnerabilities fixed under CVE-2025-49704 and CVE-2025-49706, but by changing just one byte in the request, we were able to bypass those fixes. In this post, we provide detailed information about CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771, and one related vulnerability. Since the exploit code is already published online, is very easy to use, and poses a significant risk, we encourage all organizations to install the necessary updates. The exploit Our research started with an analysis of a POST request dump associated with this wave of attacks on SharePoint servers. We can see that this POST request targets the “/_layouts/15/ToolPane.aspx” endpoint and embeds two parameters: “MSOtlPn_Uri” and “MSOtlPn_DWP”. Looking at the code of ToolPane.aspx, we can see that this file itself does not contain much functionality and most of its code is located in the ToolPane class of the Microsoft.SharePoint.WebPartPages namespace in Microsoft.SharePoint.dll. Looking at this class reveals the code that works with the two parameters present in the exploit. However, accessing this endpoint under normal conditions is not possible without bypassing authentication on the attacked SharePoint server. This is where the first Microsoft SharePoint Server Spoofing Vulnerability CVE-2025-49706 comes into play. CVE-2025-49706 This vulnerability is present in the method PostAuthenticateRequestHandler, in Microsoft.SharePoint.dll. SharePoint requires Internet Information Services (IIS) to be configured in integrated mode. In this mode, the IIS and ASP.NET authentication stages are unified. As a result, the outcome of IIS authentication is not determined until the PostAuthenticateRequest stage, at which point both the ASP.NET and IIS authentication methods have been completed. Therefore, the PostAuthenticateRequestHandler method utilizes a series of flags to track potential authentication violations. A logic bug in this method enables an authentication bypass if the “Referrer” header of the HTTP request is equal to “/_layouts/SignOut.aspx”, “/_layouts/14/SignOut.aspx”, or “/_layouts/15/SignOut.aspx” using case insensitive comparison. The code displayed in the image above handles the sign-out request and is also triggered when the sign-out page is specified as the referrer. When flag6 is set to false and flag7 is set to true, both conditional branches that could potentially throw an “Unauthorized Access” exception are bypassed. On July 8, 2025, Microsoft released an update that addressed this vulnerability by introducing additional checks to detect the usage of the “ToolPane.aspx” endpoint with the sign-out page specified as the referrer. The added check uses case insensitive comparison to verify if the requested path ends with “ToolPane.aspx”. Is it possible to bypass this check, say, by using a different endpoint? Our testing has shown that this check can be easily bypassed. CVE-2025-53771 We were able to successfully bypass the patch for vulnerability CVE-2025-49706 by adding just one byte to the exploit POST request. All that was required to bypass this patch was to add a “/” (slash) to the end of the requested “ToolPane.aspx” path. On July 20, 2025, Microsoft released an update that fixed this bypass as CVE-2025-53771. This fix replaces the “ToolPane.aspx” check to instead check whether the requested path is in the list of paths allowed for use with the sign-out page specified as the referrer. This allowlist includes the following paths: “/_layouts/15/SignOut.aspx”, “/_layouts/15/1033/initstrings.js”, “/_layouts/15/init.js”, “/_layouts/15/theming.js”, “/ScriptResource.axd”, “/_layouts/15/blank.js”, “/ScriptResource.axd”, “/WebResource.axd”, “/_layouts/15/1033/styles/corev15.css”, “/_layouts/15/1033/styles/error.css”, “/_layouts/15/images/favicon.ico”, “/_layouts/15/1033/strings.js”, “/_layouts/15/core.js”, and it can contain additional paths added by the administrator. While testing the CVE-2025-49706 bypass with the July 8, 2025 updates installed on our SharePoint debugging stand, we noticed some strange behavior. Not only did the bypass of CVE-2025-49706 work, but the entire exploit chain did! But wait! Didn’t the attackers use an additional Microsoft SharePoint Remote Code Execution Vulnerability CVE-2025-49704, which was supposed to be fixed in the same update? To understand why the entire exploit chain worked in our case, let’s take a look at the vulnerability CVE-2025-49704 and how it was fixed. CVE-2025-49704 CVE-2025-49704 is an untrusted data deserialization vulnerability that exists due to improper validation of XML content. Looking at the exploit POST request, we can see that it contains two URL encoded parameters: “MSOtlPn_Uri” and “MSOtlPn_DWP”. We can see how they are handled by examining the code of the method GetPartPreviewAndPropertiesFromMarkup in Microsoft.SharePoint.dll. A quick analysis reveals that “MSOtlPn_Uri” is a page URL that might be pointing to an any file in the CONTROLTEMPLATES folder and the parameter “MSOtlPn_DWP” contains something known as WebPart markup. This markup contains special directives that can be used to execute safe controls on a server and has a format very similar to XML. While this “XML” included in the “MSOtlPn_DWP” parameter does not itself contain a vulnerability, it allows attackers to instantiate the ExcelDataSet control from Microsoft.PerformancePoint.Scorecards.Client.dll with CompressedDataTable property set to malicious payload and trigger its processing using DataTable property getter. Looking at the code of the ExcelDataSet’s DataTable property getter in Microsoft.PerformancePoint.Scorecards.Client.dll, we find the method GetObjectFromCompressedBase64String, responsible for deserialization of CompressedDataTable property contents. The data provided as Base64 string is decoded, unzipped, and passed to the BinarySerialization.Deserialize method from Microsoft.SharePoint.dll. Attackers use this method to provide a malicious DataSet whose deserialized content is shown in the image above. It contains an XML with an element of dangerous type "System.Collections.Generic.List1[[System.Data.Services.Internal.ExpandedWrapper2[...], System.Data.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]", which allows attackers to execute arbitrary methods with the help of the well-known ExpandedWrapper technique aimed at exploitation of unsafe XML deserialization in applications based on the .NET framework. In fact, this shouldn’t be possible, since BinarySerialization.Deserialize in Microsoft.SharePoint.dll uses a special XmlValidator designed to protect against this technique by checking the types of all elements present in the provided XML and ensuring that they are on the list of allowed types. However, the exploit bypasses this check by placing the ExpandedWrapper object into the list. Now, to find out why the exploit worked on our SharePoint debugging stand with the July 8, 2025 updates installed, let’s take a look at how this vulnerability was fixed. In this patch, Microsoft did not really fix the vulnerability but only mitigated it by adding the new AddExcelDataSetToSafeControls class to the Microsoft.SharePoint.Upgrade namespace. This class contains new code that modifies the web.config file and marks the Microsoft.PerformancePoint.Scorecards.ExcelDataSet control as unsafe. Because SharePoint does not execute this code on its own after installing updates, the only way to achieve the security effect was to manually run a configuration upgrade using the SharePoint Products Configuration Wizard tool. Notably, the security guidance for CVE-2025-49704 does not mention the need for this step, which means at least some SharePoint administrators may skip it. Meanwhile, anyone who installed this update but did not manually perform a configuration upgrade remained vulnerable. CVE-2025-53770 On July 20, 2025, Microsoft released an update with a proper fix for the CVE-2025-49704 vulnerability. This patch introduces an updated XmlValidator that now properly validates element types in XML, preventing exploitation of this vulnerability without requiring a configuration upgrade and, more importantly, addressing the root cause and preventing exploitation of the same vulnerability through controls other than Microsoft.PerformancePoint.Scorecards.ExcelDataSet. CVE-2020-1147 Readers familiar with previous SharePoint exploits might feel that the vulnerability CVE-2025-49704/CVE-2025-53770 and the exploit used by the attackers looks very familiar and very similar to the older .NET Framework, SharePoint Server, and Visual Studio Remote Code Execution Vulnerability CVE-2020-1147. In fact, if we compare the exploit for CVE-2020-1147 and an exploit for CVE-2025-49704/CVE-2025-53770, we can see that they are almost identical. The only difference is that in the exploit for CVE-2025-49704/CVE-2025-53770, the dangerous ExpandedWrapper object is placed in the list. This makes CVE-2025-53770 an updated fix for CVE-2020-1147. Conclusions Despite the fact that patches for the ToolShell vulnerabilities are now available for deployment, we assess that this chain of exploits will continue being used by attackers for a long time. We have been observing the same situation with other notorious vulnerabilities, such as ProxyLogon, PrintNightmare, or EternalBlue. While they have been known for years, many threat actors still continue leveraging them in their attacks to compromise unpatched systems. We expect the ToolShell vulnerabilities to follow the same fate, as they can be exploited with extremely low effort and allow full control over the vulnerable server. To stay better protected against threats like ToolShell, we as a community should learn lessons from previous events in the industry related to critical vulnerabilities. Specifically, the speed of applying security patches nowadays is the most important factor when it comes to fighting such vulnerabilities. Since public exploits for these dangerous vulnerabilities appear very soon after vulnerability announcements, it is paramount to install patches as soon as possible, as a gap of even a few hours can make a critical difference. At the same time, it is important to protect enterprise networks against zero-day exploits, which can be leveraged when there is no available public patch for vulnerabilities. In this regard, it is critical to equip machines with reliable cybersecurity solutions that have proven effective in combatting ToolShell attacks before they were publicly disclosed. Kaspersky Next with its Behaviour detection component proactively protects against exploitation of these vulnerabilities. Additionally, it is able to detect exploitation and the subsequent malicious activity. Kaspersky products detect the exploits and malware used in these attacks with the following verdicts: UDS:DangerousObject.Multi.Generic PDM:Exploit.Win32.Generic PDM:Trojan.Win32.Generic HEUR:Trojan.MSIL.Agent.gen ASP.Agent.* PowerShell.Agent.*

On July 19–20, 2025, various security companies and national CERTs published alerts about active exploitation of on-premise SharePoint servers. According to the reports, observed attacks did not require authentication, allowed attackers to gain full control over the infected servers, and were performed using an exploit chain of two vulnerabilities: CVE-2025-49704 and CVE-2025-49706, publicly named “ToolShell”. Additionally, on the same dates, Microsoft released out-of-band security patches for the vulnerabilities CVE-2025-53770 and CVE-2025-53771, aimed at addressing the security bypasses of previously issued fixes for CVE-2025-49704 and CVE-2025-49706. The release of the new, “proper” updates has caused confusion about exactly which vulnerabilities attackers are exploiting and whether they are using zero-day exploits. Kaspersky products proactively detected and blocked malicious activity linked to these attacks, which allowed us to gather statistics about the timeframe and spread of this campaign. Our statistics show that widespread exploitation started on July 18, 2025, and attackers targeted servers across the world in Egypt, Jordan, Russia, Vietnam, and Zambia. Entities across multiple sectors were affected: government, finance, manufacturing, forestry, and agriculture. While analyzing all artifacts related to these attacks, which were detected by our products and public information provided by external researchers, we found a dump of a POST request that was claimed to contain the malicious payload used in these attacks. After performing our own analysis, we were able to confirm that this dump indeed contained the malicious payload detected by our technologies, and that sending this single request to an affected SharePoint installation was enough to execute the malicious payload there. Our analysis of the exploit showed that it did rely on vulnerabilities fixed under CVE-2025-49704 and CVE-2025-49706, but by changing just one byte in the request, we were able to bypass those fixes. In this post, we provide detailed information about CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771, and one related vulnerability. Since the exploit code is already published online, is very easy to use, and poses a significant risk, we encourage all organizations to install the necessary updates. The exploit Our research started with an analysis of a POST request dump associated with this wave of attacks on SharePoint servers. We can see that this POST request targets the “/_layouts/15/ToolPane.aspx” endpoint and embeds two parameters: “MSOtlPn_Uri” and “MSOtlPn_DWP”. Looking at the code of ToolPane.aspx, we can see that this file itself does not contain much functionality and most of its code is located in the ToolPane class of the Microsoft.SharePoint.WebPartPages namespace in Microsoft.SharePoint.dll. Looking at this class reveals the code that works with the two parameters present in the exploit. However, accessing this endpoint under normal conditions is not possible without bypassing authentication on the attacked SharePoint server. This is where the first Microsoft SharePoint Server Spoofing Vulnerability CVE-2025-49706 comes into play. CVE-2025-49706 This vulnerability is present in the method PostAuthenticateRequestHandler, in Microsoft.SharePoint.dll. SharePoint requires Internet Information Services (IIS) to be configured in integrated mode. In this mode, the IIS and ASP.NET authentication stages are unified. As a result, the outcome of IIS authentication is not determined until the PostAuthenticateRequest stage, at which point both the ASP.NET and IIS authentication methods have been completed. Therefore, the PostAuthenticateRequestHandler method utilizes a series of flags to track potential authentication violations. A logic bug in this method enables an authentication bypass if the “Referrer” header of the HTTP request is equal to “/_layouts/SignOut.aspx”, “/_layouts/14/SignOut.aspx”, or “/_layouts/15/SignOut.aspx” using case insensitive comparison. The code displayed in the image above handles the sign-out request and is also triggered when the sign-out page is specified as the referrer. When flag6 is set to false and flag7 is set to true, both conditional branches that could potentially throw an “Unauthorized Access” exception are bypassed. On July 8, 2025, Microsoft released an update that addressed this vulnerability by introducing additional checks to detect the usage of the “ToolPane.aspx” endpoint with the sign-out page specified as the referrer. The added check uses case insensitive comparison to verify if the requested path ends with “ToolPane.aspx”. Is it possible to bypass this check, say, by using a different endpoint? Our testing has shown that this check can be easily bypassed. CVE-2025-53771 We were able to successfully bypass the patch for vulnerability CVE-2025-49706 by adding just one byte to the exploit POST request. All that was required to bypass this patch was to add a “/” (slash) to the end of the requested “ToolPane.aspx” path. On July 20, 2025, Microsoft released an update that fixed this bypass as CVE-2025-53771. This fix replaces the “ToolPane.aspx” check to instead check whether the requested path is in the list of paths allowed for use with the sign-out page specified as the referrer. This allowlist includes the following paths: “/_layouts/15/SignOut.aspx”, “/_layouts/15/1033/initstrings.js”, “/_layouts/15/init.js”, “/_layouts/15/theming.js”, “/ScriptResource.axd”, “/_layouts/15/blank.js”, “/ScriptResource.axd”, “/WebResource.axd”, “/_layouts/15/1033/styles/corev15.css”, “/_layouts/15/1033/styles/error.css”, “/_layouts/15/images/favicon.ico”, “/_layouts/15/1033/strings.js”, “/_layouts/15/core.js”, and it can contain additional paths added by the administrator. While testing the CVE-2025-49706 bypass with the July 8, 2025 updates installed on our SharePoint debugging stand, we noticed some strange behavior. Not only did the bypass of CVE-2025-49706 work, but the entire exploit chain did! But wait! Didn’t the attackers use an additional Microsoft SharePoint Remote Code Execution Vulnerability CVE-2025-49704, which was supposed to be fixed in the same update? To understand why the entire exploit chain worked in our case, let’s take a look at the vulnerability CVE-2025-49704 and how it was fixed. CVE-2025-49704 CVE-2025-49704 is an untrusted data deserialization vulnerability that exists due to improper validation of XML content. Looking at the exploit POST request, we can see that it contains two URL encoded parameters: “MSOtlPn_Uri” and “MSOtlPn_DWP”. We can see how they are handled by examining the code of the method GetPartPreviewAndPropertiesFromMarkup in Microsoft.SharePoint.dll. A quick analysis reveals that “MSOtlPn_Uri” is a page URL that might be pointing to an any file in the CONTROLTEMPLATES folder and the parameter “MSOtlPn_DWP” contains something known as WebPart markup. This markup contains special directives that can be used to execute safe controls on a server and has a format very similar to XML. While this “XML” included in the “MSOtlPn_DWP” parameter does not itself contain a vulnerability, it allows attackers to instantiate the ExcelDataSet control from Microsoft.PerformancePoint.Scorecards.Client.dll with CompressedDataTable property set to malicious payload and trigger its processing using DataTable property getter. Looking at the code of the ExcelDataSet’s DataTable property getter in Microsoft.PerformancePoint.Scorecards.Client.dll, we find the method GetObjectFromCompressedBase64String, responsible for deserialization of CompressedDataTable property contents. The data provided as Base64 string is decoded, unzipped, and passed to the BinarySerialization.Deserialize method from Microsoft.SharePoint.dll. Attackers use this method to provide a malicious DataSet whose deserialized content is shown in the image above. It contains an XML with an element of dangerous type "System.Collections.Generic.List1[[System.Data.Services.Internal.ExpandedWrapper2[...], System.Data.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]", which allows attackers to execute arbitrary methods with the help of the well-known ExpandedWrapper technique aimed at exploitation of unsafe XML deserialization in applications based on the .NET framework. In fact, this shouldn’t be possible, since BinarySerialization.Deserialize in Microsoft.SharePoint.dll uses a special XmlValidator designed to protect against this technique by checking the types of all elements present in the provided XML and ensuring that they are on the list of allowed types. However, the exploit bypasses this check by placing the ExpandedWrapper object into the list. Now, to find out why the exploit worked on our SharePoint debugging stand with the July 8, 2025 updates installed, let’s take a look at how this vulnerability was fixed. In this patch, Microsoft did not really fix the vulnerability but only mitigated it by adding the new AddExcelDataSetToSafeControls class to the Microsoft.SharePoint.Upgrade namespace. This class contains new code that modifies the web.config file and marks the Microsoft.PerformancePoint.Scorecards.ExcelDataSet control as unsafe. Because SharePoint does not execute this code on its own after installing updates, the only way to achieve the security effect was to manually run a configuration upgrade using the SharePoint Products Configuration Wizard tool. Notably, the security guidance for CVE-2025-49704 does not mention the need for this step, which means at least some SharePoint administrators may skip it. Meanwhile, anyone who installed this update but did not manually perform a configuration upgrade remained vulnerable. CVE-2025-53770 On July 20, 2025, Microsoft released an update with a proper fix for the CVE-2025-49704 vulnerability. This patch introduces an updated XmlValidator that now properly validates element types in XML, preventing exploitation of this vulnerability without requiring a configuration upgrade and, more importantly, addressing the root cause and preventing exploitation of the same vulnerability through controls other than Microsoft.PerformancePoint.Scorecards.ExcelDataSet. CVE-2020-1147 Readers familiar with previous SharePoint exploits might feel that the vulnerability CVE-2025-49704/CVE-2025-53770 and the exploit used by the attackers looks very familiar and very similar to the older .NET Framework, SharePoint Server, and Visual Studio Remote Code Execution Vulnerability CVE-2020-1147. In fact, if we compare the exploit for CVE-2020-1147 and an exploit for CVE-2025-49704/CVE-2025-53770, we can see that they are almost identical. The only difference is that in the exploit for CVE-2025-49704/CVE-2025-53770, the dangerous ExpandedWrapper object is placed in the list. This makes CVE-2025-53770 an updated fix for CVE-2020-1147. Conclusions Despite the fact that patches for the ToolShell vulnerabilities are now available for deployment, we assess that this chain of exploits will continue being used by attackers for a long time. We have been observing the same situation with other notorious vulnerabilities, such as ProxyLogon, PrintNightmare, or EternalBlue. While they have been known for years, many threat actors still continue leveraging them in their attacks to compromise unpatched systems. We expect the ToolShell vulnerabilities to follow the same fate, as they can be exploited with extremely low effort and allow full control over the vulnerable server. To stay better protected against threats like ToolShell, we as a community should learn lessons from previous events in the industry related to critical vulnerabilities. Specifically, the speed of applying security patches nowadays is the most important factor when it comes to fighting such vulnerabilities. Since public exploits for these dangerous vulnerabilities appear very soon after vulnerability announcements, it is paramount to install patches as soon as possible, as a gap of even a few hours can make a critical difference. At the same time, it is important to protect enterprise networks against zero-day exploits, which can be leveraged when there is no available public patch for vulnerabilities. In this regard, it is critical to equip machines with reliable cybersecurity solutions that have proven effective in combatting ToolShell attacks before they were publicly disclosed. Kaspersky Next with its Behaviour detection component proactively protects against exploitation of these vulnerabilities. Additionally, it is able to detect exploitation and the subsequent malicious activity. Kaspersky products detect the exploits and malware used in these attacks with the following verdicts: UDS:DangerousObject.Multi.Generic PDM:Exploit.Win32.Generic PDM:Trojan.Win32.Generic HEUR:Trojan.MSIL.Agent.gen ASP.Agent.* PowerShell.Agent.*