Search/ClickFix Attacks Against macOS Users Evolving
● Story

ClickFix Attacks Against macOS Users Evolving

ClickFix attacks have evolved to feature videos that guide victims through the self-infection process, a timer to pressure targets into taking risky actions, and automatic detection of the operating system to provide the correct commands. In a typical ClickFix attack, the threat actor relies on social-engineering to trick users into pasting and executing code or commands from a malicious page. The lures used may vary from identity verification to software problem solutions. The goal is to make the target execute malware that fetches and launches a payload, usually an information stealer. Most of the times, these attacks provided text instructions on a web page but newer versions rely on an embedded video to make the attack less suspicious. Push Security researchers have spotted this…

View graph Export
CVEs
0
Highest CVSS
—
In KEV
0
Sources
7
Connections
21 relationships
SmartApeSG campaign uses ClickFix page to push NetSupport RAT, (Wed, Nov 12th)
Introduction This diary describes a NetSupport RAT infection I generated in my lab from the SmartApeSG campaign that used a ClickFix-style fake CAPTCHA page. Known as ZPHP or HANEYMANEY, SmartApeSG is a campaign reported as early as June 2024. When it started, this campaign used fake browser update pages. But it currently uses the ClickFix method of fake CAPTCHA-style "verify you are human" pages. This campaign pushes malicious NetSupport RAT packages for its initial malware infection, and I've seen follow-up malware from these NetSupport RAT infections. How To Find SmartApeSG Activity I can usually find SmartApeSG indicators from the Monitor SG account on Mastodon. I use URLscan to pivot on those indicators, so I can find compromised websites that lead to the SmartApeSG script. The Infection Sites compromised through this campaign display pages with a hidden injected script. Given the right conditions, this script kicks off a SmartApeSG chain of events. The image below shows an example. Shown above: Injected SmartApeSG script in a page from the compromised site. In some cases, this injected script does not kick off the infection chain. I've had issues getting an infection chain during certain times of day, or if I try viewing the compromised website multiple times from the same source IP address. I don't know what the conditions are, but if those conditions are right, the compromised site shows a fake CAPTCHA-style "verify you are human" page. Shown above: Fake CAPTCHA page displayed by the compromised site. Clicking the "verify you are human" box does the following: Injects malicious content into the Windows host's clipboard Generates a pop-up with instructions to open a Run window, paste content into the window, and run it. The clipboard-injected content is a command string that uses the mshta command to retrieve and run malicious content that will generate a NetSupport RAT infection. Shown above: Following ClickFix directions to paste content (a malicious command) into the Run window. Below is a URL list of the HTTPS traffic directly involved in this infection. Shown above: HTTPS traffic directly involved in this SmartApe SG activity. Shown above: Traffic from the infection filtered in Wireshark. The malicious NetSupport RAT package stays persistent on the infected host through a Start Menu shortcut. The shortcut runs a .js file in the user's AppData\Local\Temp directory. That .js file runs the NetSupport RAT executable located in a folder under the C:\ProgramData\ directory. Shown above: The malicious NetSupport RAT package, persistent on an infected Windows host. Indicators From This Activity The following URLs were noted in traffic from this infection: hxxps[:]//frostshiledr[.]com/xss/buf.js <-- injected SmartApeSG script hxxps[:]//frostshiledr[.]com/xss/index.php?iArfLYKw hxxps[:]//frostshiledr[.]com/xss/bof.js?0e58069bbdd36e9a36 <-- fake CAPCHA page/ClickFix instructions hxxps[:]//newstarmold[.]com/sibhl.php <-- Script retrieved by ClickFix command hxxps[:]//www.iconconsultants[.]com/4nnjson.zip <-- zip archive containing malicious NetSupport RAT package hxxp[:]//194.180.191[.]121/fakeurl.htm <-- NetSupport RAT C2 traffic over TCP port 443 The following is the zip archive containing the malicious NetSupport RAT package: SHA256 hash: 1e9a1be5611927c22a8c934f0fdd716811e0c93256b4ee784fadd9daaf2459a1 File size: 9,192,105 bytes File type: Zip archive data, at least v1.0 to extract, compression method=store File location: hxxps[:]//www.iconconsultants[.]com/4nnjson.zip Saved to disk as: C:\ProgramData\psrookk11nn.zip Note: These domains change on a near-daily basis, and the NetSupport RAT package and C2 server also frequently change. --- Bradley Duncan brad [at] malware-traffic-analysis.net
isc.sans.eduNov 12, 2025extracted
What is FileFix — a ClickFix variation? | Kaspersky official blog
We recently covered the ClickFix technique. Now, malicious actors have begun deploying a new twist on it, which was dubbed “FileFix” by researchers. The core principle remains the same: using social engineering tactics to trick the victim into unwittingly executing malicious code on their own device. The difference between ClickFix and FileFix is essentially where the command is executed. With ClickFix, attackers convince the victim to open the Windows Run dialog box and paste a malicious command into it. With FileFix, however, they manipulate the victim into pasting a command into the Windows File Explorer address bar. From a user perspective, this action doesn’t appear unusual — the File Explorer window is a familiar element, making its use less likely to be perceived as dangerous. Consequently, users unfamiliar with this particular ploy are significantly more prone to falling for the FileFix trick. How attackers manipulate the victim into executing their code Similar to ClickFix, a FileFix attack begins when a user is directed — most often via a phishing email — to a page that mimics the website of some legitimate online service. The fake site displays an error message preventing access to the service’s normal functionality. To resolve the issue, the user is told they need to perform a series of steps for an “environment check” or “diagnostic” process. To do this, the user is told they need to run a specific file that, according to the attackers, is either already on the victim’s computer or has just been downloaded. All the user needs to do is copy the path to the local file and paste it into the Windows File Explorer address bar. Indeed, the field from which the user is instructed to copy the string shows the path to the file — which is why the attack is named “FileFix”. The user is then instructed to open File Explorer, press [CTRL] + [L] to focus on the address bar, paste the “file path” via [CTRL] + [V], and press [ENTER]. Here’s the trick: the visible file path is only the last few dozen characters of a much longer command. Preceding the file path is a string of spaces, and before that is the actual malicious payload the attackers intend to execute. The spaces are crucial for ensuring the user doesn’t see anything suspicious after pasting the command. Because the full string is significantly longer than the address bar’s visible area, only the benign file path remains in view. The true contents are only revealed if the information is pasted into a text file instead of the File Explorer window. For instance, in a Bleeping Computer article based on research by Expel, the actual command was found to launch a PowerShell script via conhost.exe. What happens after the malicious script is run A PowerShell script executed by a legitimate user can cause trouble in a multitude of ways. Everything depends on corporate security policies, the specific user’s privileges, and the presence of security solutions on the victim’s computer. In the case mentioned previously, the attack utilized a technique named “cache smuggling”. The same fake website that implemented the FileFix trick saved a file in JPEG format into the browser’s cache, but the file actually contained an archive with malware. The malicious script then extracted this malware and executed it on the victim’s computer. This method allows the final malicious payload to be delivered to the computer without overt file downloads or suspicious network requests, making it particularly stealthy. How to defend your company against ClickFix and FileFix attacks In our post about the ClickFix attack technique, we suggested that the simplest defense was to block the [Win] + [R] key combination on work devices. It’s extremely rare for a typical office employee to genuinely need to open the Run dialog box. In the case of FileFix, the situation is a bit more complex: copying a command into the address bar is perfectly normal user behavior. Blocking the [CTRL] + [L] shortcut is generally undesirable for two reasons. First, this combination is frequently used in various applications for diverse, legitimate purposes. Second, it wouldn’t fully help, as users can still access the File Explorer address bar by simply clicking it with the mouse. Attackers often provide detailed instructions for users if the keyboard shortcut fails. Therefore, for a truly effective defense against ClickFix, FileFix, and similar schemes, we recommend first and foremost deploying a reliable security solution on all employee work devices that can detect and block the execution of dangerous code in time. Second, we advise regularly raising employee awareness about modern cyberthreats — particularly the social engineering methods employed in ClickFix and FileFix scenarios. The Kaspersky Automated Security Awareness Platform can help automate employee training.
kaspersky.comNov 10, 2025extracted
Large-Scale ClickFix Phishing Attacks Target Hotel Systems with PureRAT Malware
Cybersecurity researchers have called attention to a massive phishing campaign targeting the hospitality industry that lures hotel managers to ClickFix-style pages and harvest their credentials by deploying malware like PureRAT. "The attacker's modus operandi involved using a compromised email account to send malicious messages to multiple hotel establishments," Sekoia said. "This campaign leverages spear-phishing emails that impersonate Booking.com to redirect victims to malicious websites, employing the ClickFix social engineering tactic to deploy PureRAT." The end goal of the campaign is to steal credentials from compromised systems that grant threat actors unauthorized access to booking platforms like Booking.com or Expedia, which are then either sold on cybercrime forums or used to send fraudulent emails to hotel customers to conduct fraud. The activity is assessed to be active since at least April 2025 and operational as of early October 2025. It's one of the several campaigns that has been observed targeting booking platform accounts, including a set of attacks that was documented by Microsoft earlier this March. In the latest wave analyzed by the French cybersecurity company, emails messages are sent from a compromised email account to target several hotels across multiple countries, tricking recipients into clicking on bogus links that triggers a redirection chain to a ClickFix page with a supposed reCAPTCHA challenge to "ensure the security of your connection." "Upon visiting, the URL redirects users to a web page hosting a JavaScript with an asynchronous function that, after a brief delay, checks whether the page was displayed inside an iframe," Sekoia explained. "The objective is to redirect the user to the same URL but over HTTP." This causes the victim to copy and execute a malicious PowerShell command that gathers system information and downloads a ZIP archive, which, in turn, contains a binary that ultimately sets up persistence and loads PureRAT (aka zgRAT) by means of DLL side-loading. The modular malware supports a wide range of features, such as remote access, mouse and keyboard control, webcam and microphone capture, keylogging, file upload/download, traffic proxying, data exfiltration, and remote execution of commands or binaries. It's also protected by .NET Reactor to complicate reverse engineering and also establishes persistence on the host by creating a Run registry key. Furthermore, the campaign has been found to approach hotel customers via WhatsApp or email with legitimate reservation details, while instructing them to click on a link as part of a verification process and confirm their banking card details in order to prevent their bookings from being canceled. Unsuspecting users who end up clicking on the link are taken to a bogus landing page that mimics Booking.com or Expedia, but, in reality, is designed to steal their card information. It's assessed that the threat actors behind the scheme are procuring information about administrators of Booking.com establishments from criminal forums like LolzTeam, in some cases even offering a payment based on a percentage of the profit. The acquired details are then used to social engineer them into infecting their systems with an infostealer or remote access trojan (RAT). This task is selectively outsourced to traffers, who are dedicated specialists in charge of malware distribution. "Booking.com extranet accounts play a crucial role in fraudulent schemes targeting the hospitality industry," Sekoia said. "Consequently, data harvested from these accounts has become a lucrative commodity, regularly offered for sale in illicit marketplaces." "Attackers trade these accounts as authentication cookies or login/password pairs extracted from infostealer logs, given that this harvested data typically originates from malware compromise on hotel administrators' systems." The company said it observed a Telegram bot to buy Booking.com logs, as well as a threat actor named "moderator_booking" advertising a Booking log purchase service to obtain logs associated with Booking.com, Expedia, Airbnb, and Agoda. They claim the logs are manually checked within 24-48 hours. This is typically accomplished by means of log checker tools, available for as low as $40 on cybercrime forums, that authenticate compromised accounts via proxies to ensure that the harvested credentials are still valid. "The proliferation of cybercrime services supporting each step of the Booking.com attack chain reflects a professionalization of this fraud model," Sekoia said. "By adopting the 'as-a-service' model, cybercriminals lower entry barriers and maximise profits." The development comes as Push Security detailed an update to the ClickFix social engineering tactic that makes it even more convincing to users by including an embedded video, countdown timer, and a counter for "users verified in the last hour" along with the instructions to increase the perceived authenticity and trick the user into completing the check without thinking too much. Another notable update is that the page is capable of adapting itself to display instructions that match the victim's operating system, asking them to open the Windows Run dialog or the macOS Terminal app depending on the device they are visiting from. The pages are also increasingly equipped to automatically copy the malicious code to the user's clipboard, a technique called clipboard hijacking. "ClickFix pages are becoming increasingly sophisticated, making it more likely that victims will fall for the social engineering," Push Security said. "ClickFix payloads are becoming more varied and are finding new ways to evade security controls."
thehackernews.comNov 10, 2025extracted
ClickFix Attacks Against macOS Users Evolving
ClickFix attacks continue to evolve and the technique appears to be increasingly used against macOS users, with lures becoming ever more convincing. ClickFix has been widely adopted by both profit-driven cybercriminals and state-sponsored threat groups. The social engineering tactic enables attackers to trick victims into inadvertently executing malicious commands, particularly ones that lead to the deployment of malware. An attack involves a fake error message being displayed, informing the targeted user that in order to ‘fix’ the issue they need to click on a button and execute a series of operations. When the user clicks the ‘fix’ or ‘verify’ button in the prompt, a malicious command is copied in the background to their clipboard. On Windows, the victim is then instructed to press the Windows+R keys, which opens the Windows Run dialog box, then press Ctrl+V, which pastes the malicious command from the clipboard into the box, and finally press Enter to execute the command. The command typically runs silently in the background (often by leveraging a legitimate Windows utility such as PowerShell), downloading and installing a piece of malware. Since the victim is manually executing the command and installing the malware, security systems that would typically catch an automated download of the malware are more likely to be bypassed. ClickFix attacks have been conducted primarily against Windows users, but there have also been reports of attacks targeting macOS users, and the attacks aimed at macOS users appear to have significantly evolved in recent months. For instance, a few months ago Microsoft warned about a ClickFix campaign where fake Cloudflare verification instructions displayed in the malicious prompt to macOS users contained instructions actually meant for Windows users. CrowdStrike recently reported seeing a ClickFix attack whose goal was the deployment of a piece of malware named SHAMOS, a variant of the macOS information stealer AMOS. The fake instructions for the victims were adapted to macOS, with users being instructed to press the Command and Space keys to open Spotlight Search, type ‘Terminal’, and execute a given command. However, the number of steps that needed to be completed was higher than on Windows and it was likely to raise more suspicion as the victim was instructed to manually copy a given command, paste it into a Terminal window, and execute it. During the process, macOS may have also prompted the victim to enter their system password, which could further raise suspicion. Browser threat detection and response firm Push Security on Thursday reported seeing what it described as the “most advanced ClickFix” to date. The ClickFix pop-up mimics a Cloudflare verification page and it’s well designed. The instructions are tailored to macOS users, there are fewer steps to complete compared to the attacks seen by CrowdStrike, and the malicious command is apparently automatically copied to the user’s clipboard. In addition, the page includes an embedded video that shows the user how to carry out the instructions to ‘verify’ that they are human. It also displays a countdown timer to put pressure on the victim. Targeting macOS users in a malware distribution campaign is in general more challenging compared to Windows, but the latest improvements in ClickFix attacks demonstrate that threat actors are rapidly adapting their tactics. Due to the nature of ClickFix attacks, the measures that operating system and security vendors can take to protect users are limited. Microsoft, for instance, has been adding ClickFix defenses to its Defender products, particularly for the detection of malicious ClickFix landing pages, but highlighted that user training and awareness are critical. SecurityWeek has reached out to Apple to find out whether it’s taking any steps to protect users against ClickFix attacks. Related: New Interlock RAT Variant Distributed via FileFix Attacks Related: New ClickFix Malware Variant ‘LightPerlGirl’ Targets Users in Stealthy Hack Related: ClickFix Attack Exploits Fake Cloudflare Turnstile to Deliver Malware
securityweek.comNov 7, 2025extracted
Attackers upgrade ClickFix with tricks used by online stores
Attackers upgrade ClickFix with tricks used by online stores Attackers have taken the ClickFix technique further, with pages borrowing tricks from online sellers to pressure victims into performing the steps that will lead to a malware infection. Push Security has spotted one of these pages, showing an embedded tutorial video on how to perform the asked-for actions, a timer ostensibly counting down the seconds left to act, and a “users verified in the last hour” counter – all aimed at pressing users to act quickly, without thinking. The advanced ClickFix page (Source: Push Security) “This is an incredibly slick example – it almost looks like Cloudflare shipped a new kind of bot check service,” the researchers noted. To make the illusion of legitimacy complete, the page adapts to serve the correct instructions depending on the visitors’ operating system, and it’s automatically copying the malicious code to the user’s clipboard via JavaScript. These features make the pages look credible and make the action feel normal, like completing a checkout or confirming an order.  ClickFix’s rise The ClickFix technique was named after the initial pretext used by the attackers: the malicious pages would show a fake error message and would instruct users to copy and run some code to fix the problem. Malicious websites using the “click-to-fix” pretext (Source: Sekoia) In time, the FakeCaptcha (“prove that you’re a human”) pretext became more popular, but the ClickFix name stuck, and technique became hugely popular state-sponsored threat actors. “According to the 2025 Microsoft Digital Defense report, ClickFix was the most common initial access method in the last year, accounting for 47% of attacks,” Push Security pointed out. Multi-channel distribution ClickFix lures are distributed via various channels: email, instant messengers, social networks, in-app phishing, and malvertising (on search engines, YouTube, and Steam). Malicious ads and highly-ranked pages surfaced by Google Search are currently the top delivery vector for ClickFix attacks, the researchers added. “While other examples may have been stopped by controls such as email before the page could be loaded by the user, this shows a significant monitoring gap when it comes to non-email delivery vectors,” the company added. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!
helpnetsecurity.comNov 7, 2025extracted
“I Paid Twice” Phishing Campaign Targets Booking.com
A large-scale phishing operation exploiting Booking.com partner accounts has been uncovered by cybersecurity experts The latest Sekoia.io report, published today, detailed how cybercriminals compromised hotel systems and customer data through a sophisticated malware campaign active since at least April 2025. The intrusion began when attackers sent malicious emails from legitimate hotel accounts or impersonated Booking.com. Each message contained a link leading victims through a redirection chain before launching the so-called ClickFix social engineering tactic. Victims were prompted to execute a PowerShell command that downloaded malware, ultimately infecting systems with the PureRAT remote access Trojan. PureRAT allows attackers to remotely control infected machines, steal credentials, capture screenshots and exfiltrate sensitive data. Its modular design enables the addition of plugins for expanded capabilities. Analysts believe the malware initially targeted hotel staff to steal login credentials for booking platforms such as Booking.com, Airbnb and Expedia. These credentials were then either sold on cybercrime forums or used directly in fraudulent schemes. Once in possession of partner credentials, threat actors contacted hotel guests via email or WhatsApp, claiming issues with banking verification. Messages included authentic booking details, increasing their credibility. Victims were directed to fake Booking.com pages designed to harvest payment information. These sites, hosted behind Cloudflare protection and linked to Russian infrastructure, mimicked legitimate layouts to avoid detection. Sekoia.io analysts also observed an active trade in Booking.com credentials on Russian-language forums. Access details for these accounts (sold as authentication cookies or login pairs) ranged from $5 to $5,000, depending on value. One user, “moderator_booking,” allegedly claimed over $20m in profits. Attackers have since expanded operations to include Agoda accounts. The campaign demonstrates the growing professionalization of cybercrime targeting hospitality businesses. “We assess with high confidence that the client who fell victim to this fraudulent scheme paid twice for his reservation: once at the hotel and once to the cybercriminal,” Sekoia.io wrote. “Unveiling the adversary infrastructure revealed hundreds of malicious domains active for several months as of October 2025, demonstrating a resilient and likely profitable campaign.” The firm added it continues to monitor adversary infrastructure and improve detection methods to help protect booking platforms and their customers.
infosecurity-magazine.comNov 6, 2025extracted
ClickFix malware attacks evolve with multi-OS support, video tutorials
ClickFix attacks have evolved to feature videos that guide victims through the self-infection process, a timer to pressure targets into taking risky actions, and automatic detection of the operating system to provide the correct commands. In a typical ClickFix attack, the threat actor relies on social-engineering to trick users into pasting and executing code or commands from a malicious page. The lures used may vary from identity verification to software problem solutions. The goal is to make the target execute malware that fetches and launches a payload, usually an information stealer. Most of the times, these attacks provided text instructions on a web page but newer versions rely on an embedded video to make the attack less suspicious. Push Security researchers have spotted this change in recent ClickFix campaigns, where a fake Cloudflare CAPTCHA verification challenge detected the victim’s OS and loaded a video tutorial on how to paste and run the malicious commands. Through a JavaScript, the threat actor can hide the commands and copy them automatically into the user's clipboard, thus reducing the chances of human error. On the same window, the challenge included a one-minute countdown timer that presses the victim into taking quick action and leaving little time to verify the authenticity or safety of the verification process. Adding to the deception is a “users verified in the last hour” counter, making the window appear as part of a legitimate Cloudflare bot check tool. Although we have seen ClickFix attacks against all major operating systems before, including macOS and Linux, the automatic detection and adjustment of the instructions is a new development. Push Security reports that these more advanced ClickFix webpages are promoted primarily through malvertizing on Google Search. The threat actors either exploit known flaws on outdated WordPress plugins to compromise legitimate sites and inject their malicious JavaScript on pages, or “vibe-code” sites and use SEO poisoning tactics to rank them higher up in the search results. Regarding the payloads delivered in these attacks, Push researchers noticed that they depended on the operating system, but included the MSHTA executable in Windows, PowerShell scripts, and various other living-off-the-land binaries. The researchers speculate that future ClickFix attacks could run entirely in the browser, evading EDR protections. As ClickFix evolves and takes more convincing and deceptive forms, users should remember that executing code on the terminal can never be a part of any online-based verification process, and no copied commands should ever be executed unless the user fully understands what they do. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report
bleepingcomputer.comNov 6, 2025extracted
Related Stories
6
PHP web runtimes (CVE-2026-109618 and CVE-2026-109619)
On October 21, 2026, the PHP project released emergency fixes for two critical remote code execution (RCE) vulnerabilities in the PHP core runtime, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively named PHP2Shell. Both are rated 9.2 (Critical) under CVSS v4.0, and both allow an unauthenticated attacker to run code on a vulnerable server. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Patching is the only complete fix, and you should upgrade PHP as your first priority. But patching a fleet takes time: you need to inventory where PHP runs, schedule maintenance windows and test applications against the new builds. This post shows you how to use AWS Web Application Firewall ( AWS WAF ) to help reduce exposure to the confirmed attack paths during that window. You’ll learn which request patterns to block, how to write the rules in AWS WAFv2, how to deploy them without breaking legitimate traffic and where its protection ends, so you don’t develop a false sense of safety. For how Amazon threat intelligence detected PHP2Shell exploitation before public disclosure, see Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot . For AWS service status and the AWS WAF rule that AWS recommends, see AWS Security Bulletin 2026-143-AWS . IMPORTANT: Patching is the only complete fix, and you should upgrade PHP as your first priority. The vulnerabilities in brief Both PHP2Shell vulnerabilities are unauthenticated RCE issues rooted in how PHP handles multipart/form-data request processing (the request format browsers use for file uploads) before your application code runs, which is why the AWS WAF rules in this post focus on multipart traffic, request body size, and the session upload progress field. At a high level, CVE-2026-109618 corrupts memory when PHP runs out of memory mid-request, and CVE-2026-109619 lets one request leave behind stale data that a later request on the same worker process reuses. For the root-cause analysis, affected versions, and PHP’s own guidance, see the official PHP advisories and release announcement: CVE-2026-109618 (out-of-memory corruption) – PHP advisory GHSA-w8hw-w9fx-j79w CVE-2026-109619 (stale global state) – PHP advisory GHSA-6wmf-4rv5-p3rp PHP security release announcement, October 21, 2026 Where AWS WAF fits in your response AWS WAF is a defense-in-depth control in this situation, not a replacement for the PHP upgrade. The PHP advisories are explicit: updating to a patched release is the only complete mitigation. One of the two vulnerabilities is largely outside the reach of any web application firewall, as explained later. Treat the rules in this post as mitigating controls that help reduce exposure while you patch, then remove them or keep them as supporting controls after you’ve patched. AWS WAF inspects HTTP requests at the edge. It doesn’t parse the internal structure of a multipart body, and it has no visibility into PHP worker memory or server-side configuration. The following table maps each attack element to whether AWS WAF can help mitigate it. Attack element AWS WAF coverage Session upload progress field in a multipart POST ( PHP_SESSION_UPLOAD_PROGRESS , the form field that turns on PHP’s upload-tracking feature) Yes. A targeted rule can block requests carrying that field. Multipart upload path ( multipart/form-data , the request type used for file uploads and the entry point for both vulnerabilities) Yes, if the application has no legitimate multipart uploads. Block multipart/form-data. Out-of-memory condition from an oversized body Partial. Cap the request body size. Doesn’t catch header amplification (many small part headers that cost far more memory to represent than their size on the wire) that stays under the cap. Repeated attempts against the same worker (the reused PHP process that handles many requests) Yes. A rate-based rule blunts the volume an exploit needs. fatal_error_backtraces producer (a PHP 8.5 setting that stores crash-trace state across a request) No. This is a server configuration setting ( fatal_error_backtraces=0 ). Invalid or deprecated INI diagnostics as a consumer (warnings PHP raises when applying bad configuration settings) No. This path runs server-side, not over client HTTP. Where an application does not accept multipart uploads, an edge rule that blocks multipart/form-data removes the multipart out-of-memory path that works against any application, plus the session-upload-progress trigger, which is a defense-in-depth control during the patch window. If your application does use multipart uploads, AWS WAF reduces risk but does not close the vulnerability, because header amplification (a few kilobytes of part headers that expand into far more memory inside PHP) stays within size limits and the firewall cannot parse the headers inside individual body parts. In that case, prioritize the PHP upgrade and apply the server-side mitigations described later. Implementing the AWS WAF rules The rules below are AWS WAFv2 JSON, deploy each of them on the WAF protection pack (web ACL) associated with the Amazon CloudFront distribution, Application Load Balancer, or Amazon API Gateway stage in front of your PHP workloads. IMPORTANT: Before implementing any changes, ensure that your WAFv2 logging is setup in line with AWS WAF Logging guidance. Start every rule in Count mode, confirm it does not match legitimate traffic, then switch to Block. Request body inspection limits AWS WAF inspects a bounded portion of the request body. On Application Load Balancer and AWS AppSync the limit is a fixed 8 KB. For AWS services such as CloudFront and API Gateway, the default is 16 KB and you can raise it to 32, 48, or 64 KB through the web ACL AssociationConfig as seen below. Any part of the body beyond the inspection limit counts as oversize. Choose the limit that fits the rules you deploy, because a body-size rule can only enforce a cap up to the inspected size. aws wafv2 update-web-acl ... --association-config \ 'RequestBody={CLOUDFRONT={DefaultSizeInspectionLimit=KB_16}}' AWS WAF Rule This rule targets both CVEs by blocking a request only when all three conditions in its AndStatement are true at once: The method is exactly POST – matched on the HTTP method, no transformation. A PHP session identifier is present (the nested OrStatement , so either sub-condition satisfies this leg): PHPSESSID appears as a cookie key (exact match on the key, scanning all cookies), or PHPSESSID appears anywhere in the request body (contains match). The body contains PHP_SESSION_UPLOAD_PROGRESS – the form field that activates PHP’s session upload progress feature. Pair the rule with session.upload_progress.enabled=0 on the server, which turns the feature off. { "Name": "PHP2Shell", "Priority": 0, "Statement": { "AndStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "POST", "FieldToMatch": { "Method": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "EXACTLY" } }, { "OrStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "PHPSESSID", "FieldToMatch": { "Cookies": { "MatchPattern": { "All": {} }, "MatchScope": "KEY", "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "EXACTLY" } }, { "ByteMatchStatement": { "SearchString": "PHPSESSID", "FieldToMatch": { "Body": { "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } ] } }, { "ByteMatchStatement": { "SearchString": "PHP_SESSION_UPLOAD_PROGRESS", "FieldToMatch": { "Body": { "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2Shell" } } Additional WAF Rules to consider Block multipart requests when the application has no uploads NOTE: This rule, if implemented in Block mode, will break applications that require file uploads. If your application does not require file uploads, then blocking multipart/form-data removes the multipart out-of-memory path that works against any application for both CVEs at the edge. A single named header is inspected in full, with no 8 KB header cap, so matching the Content-Type header is reliable. { "Name": "Block-Multipart-FormData", "Priority": 1, "Action": { "Count": {} }, "Statement": { "ByteMatchStatement": { "FieldToMatch": { "SingleHeader": { "Name": "content-type" } }, "PositionalConstraint": "CONTAINS", "SearchString": "multipart/form-data", "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellBlockMultipart" } } Cap the request body size Capping body size reduces the out-of-memory condition behind CVE-2026-109618 and the stale state it can leave behind. Use OversizeHandling: MATCH with a size constraint so that any body larger than the threshold is blocked, including bodies that exceed the inspection limit. To enforce a cap of N bytes, the web ACL body inspection limit must be at least N. Note that you can’t cap the numeric Content-Length with a size constraint, because the constraint measures the length of the header value string, not the number it contains. If your application has legitimate large uploads, scope this rule to non-upload paths with an AndStatement on the URI path, or it will break those uploads. { "Name": "Block-Oversize-Body", "Priority": 3, "Action": { "Count": {} }, "Statement": { "SizeConstraintStatement": { "FieldToMatch": { "Body": { "OversizeHandling": "MATCH" } }, "ComparisonOperator": "GT", "Size": 8192, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellBlockOversizeBody" } } NOTE: if you already have the AWSManagedRulesCommonRuleSet managed rule group, the SizeRestrictions_BODY rule blocks bodies larger than 8 KB by default. If a specific managed rule breaks legitimate traffic, override that rule to Count rather than disabling the whole group. Rate-limit repeated attempts A rate-based rule on POST requests can reduce the volume an attacker can send, lowering the possibility that the vulnerabilities can be triggered by overloading the worker, while the stale-state path needs a producer request and a consumer request to land on the same worker. This rule complements a server setting of pm.max_requests=1 , which recycles the worker on each request. { "Name": "RateLimit-Posts", "Priority": 4, "Action": { "Count": {} }, "Statement": { "RateBasedStatement": { "Limit": 100, "EvaluationWindowSec": 60, "AggregateKeyType": "IP", "ScopeDownStatement": { "ByteMatchStatement": { "FieldToMatch": { "Method": {} }, "PositionalConstraint": "EXACTLY", "SearchString": "POST", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellRateLimitPosts" } } Server-side mitigations that complement AWS WAF These host and runtime changes address the parts of CVE-2026-109619 that sit below the HTTP layer a WAF inspects, so they fall outside its scope by design. Apply them alongside the AWS WAF rules as the host and runtime layer of your defense. Upgrade PHP to 8.5.12, 8.4.27, 8.3.36, or 8.2.35. This is the only complete fix. PHP 8.1 and earlier are no longer supported upstream, so check with your distribution or long-term support vendor for a backported fix, or plan a move to a supported branch. Address CVE-2026-109618 at the PHP level. Set memory_limit=-1 so applications cannot override it, and keep post_max_size low (8M where the application accepts no uploads, 32M where it does). Enforce memory bounds through container or cgroup limits, never through RLIMIT_AS or RLIMIT_DATA, which trigger the vulnerable out-of-memory path. Set fatal_error_backtraces=0 on PHP 8.5 and restart every worker. This disables the setting that stores crash-trace state across a request, one of the confirmed ways the vulnerability is triggered. Set session.upload_progress.enabled=0 and restart every worker. This turns off the upload-tracking feature that’s the other confirmed trigger, and is prudent to keep off even after patching. Prefer php.ini , FPM pool, or server startup configuration over per-request INI overrides (settings applied per request through .htaccess , php_value , or FastCGI PHP_VALUE) . Remove obsolete directives so they don’t raise diagnostic warnings. Eliminate fatal errors and execution timeouts on attacker-reachable routes, including upload, import, error-page, shutdown, serialization, and extension paths. Set pm.max_requests=1 if performance allows , so each worker process is recycled after one request, which breaks the link between the request that plants stale data and a later request that would reuse it. Turn on error logging ( log_errors=On , a working error_log , error_reporting=E_ALL ) and review your Apache, FPM, or proxy logs for repeated warnings, deprecations, fatal errors, and timeouts on attacker-controlled routes. The absence of errors is not proof of safety. Getting started Complete the following steps to get started: Inventory where PHP runs and which versions and server APIs (mod_php, FPM, FrankenPHP, LSAPI) are in use. Identify any public endpoint that accepts a request body. Decide whether each application uses multipart uploads. This determines whether you can deploy the WAF rule to block multipart requests. Create or update the web ACL in front of each PHP workload and add the applicable rules in Count mode. Raise the body inspection limit on CloudFront or API Gateway if a rule needs it. Watch the sampled requests and Amazon CloudWatch metrics for each rule. Confirm that legitimate uploads and large JSON POSTs aren’t matched. Switch the rules to Block after the metrics are clean. Order the priorities so the session upload progress and multipart rules run before the size and rate rules. Test with a benign multipart/form-data POST, an oversized body, and a request carrying PHP_SESSION_UPLOAD_PROGRESS . Expect a 403 response and the matching rule metric. In parallel, apply the PHP upgrade and the configuration mitigations. Remove or retain the AWS WAF rules as supporting controls after your fleet is patched. Conclusion The PHP2Shell vulnerabilities—CVE-2026-109618 and CVE-2026-109619—are unauthenticated RCE vulnerabilities that reach PHP before your application code runs. AWS WAF gives you a way to help narrow the attack surface during the patch window: block the session upload progress field, block multipart requests where no uploads are expected, cap request body size, and rate-limit repeated attempts. These mitigating controls can help reduce exposure, but they don’t close the vulnerabilities. Upgrade PHP to a fixed release, apply the server configuration changes, and treat the AWS WAF rules as the edge layer that supports those fixes rather than the fix itself. To learn more about the rule types used here, see the AWS WAF documentation on the web ACL body inspection limit , oversize request component handling , and handling oversize HTTP request bodies . For the vulnerability details, see the PHP advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp , and the PHP session upload progress manual . Alex Waddell Alex Waddell is a Principal Solutions Architect at AWS specializing in security within the Worldwide Specialist Organization, based in Scotland. Alex has been working in the security domain since 1999 and joined AWS in 2021 to work with customers across EMEA on cloud security architecture, identity, threat detection and application security. When he is not working, Alex enjoys spending time sampling rum from around the world (Alex is one of those rarely found Scottish people that doesn’t like whisky), walking his dogs in the local forest trails and traveling. Lawton Pittenger Lawton is a Worldwide Security Specialist Solutions Architect at AWS, based in New York City. He specializes in helping customers design and implement effective network security controls. At AWS, he works with customers at scale and collaborates closely with service teams to drive continuous improvement in security services based on customer needs and feedback. Outside of work, his interests include skateboarding, snowboarding, and spending time in nature. Ian Olson Ian is a Senior Security Specialist Solutions Architect at AWS. He helps customers automate security services to safeguard against threats like DDoS and web exploitations. Through intelligent automation, he delivers security solutions tailored to organizations of any scale. When he’s not working, Ian enjoys spending quality time with his two young children.
7 shared
Oct 22, 2026
Macfinger ClickFix campaign, (Tue, Sep 22nd)
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.&nbsp; 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.&nbsp; 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.&nbsp;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.&nbsp; 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.&nbsp; Use an up-to-date, real-time&nbsp; anti-malware solution &nbsp;with a web protection component. Educate yourself on evolving attack techniques. &nbsp;Understanding that attacks may come from unexpected vectors and evolve helps maintain vigilance. Keep reading our blog! Pro tip: &nbsp;The free&nbsp; Malwarebytes Browser Guard &nbsp;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 →
7 shared
Sep 30, 2026
Macfinger ClickFix campaign, (Tue, Sep 22nd)
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
7 shared
Sep 25, 2026
US Tops Hit List as 396 SharePoint Systems Compromised Globally
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.*
6 shared
Jul 31, 2025
Researchers uncover ClickFix-themed phishing kit
Cybersecurity researchers are calling attention to a nefarious campaign targeting WordPress sites to make malicious JavaScript injections that are designed to redirect users to sketchy sites. "Site visitors get injected content that was drive-by malware like fake Cloudflare verification," Sucuri researcher Puja Srivastava said in an analysis published last week. The website security company said it began an investigation after one of its customer's WordPress sites served suspicious third-party JavaScript to site visitors, ultimately finding that the attackers introduced malicious modifications to a theme-related file ("functions.php"). The code inserted into "functions.php" incorporates references to Google Ads, likely in an attempt to evade detection. But, in reality, it functions as a remote loader by sending an HTTP POST request to the domain "brazilc[.]com," which, in turn, responds with a dynamic payload that includes two components - A JavaScript file hosted on a remote server ("porsasystem[.]com"), which, as of writing, has been referenced on 17 websites and contains code to perform site redirects A piece of JavaScript code that creates a hidden, 1x1 pixel iframe, within which it injects code that mimics legitimate Cloudflare assets like "cdn-cgi/challenge-platform/scripts/jsd/main.js" – an API that's a core part of its bot detection and challenge platform It's worth noting that the domain "porsasystem[.]com" has been flagged as part of a traffic distribution system (TDS) called Kongtuke (aka 404 TDS, Chaya_002, LandUpdate808, and TAG-124). According to information shared by an account named "monitorsg" on Mastodon on September 19, 2025, the infection chain starts with users visiting a compromised site, resulting in the execution of "porsasystem[.]com/6m9x.js," which then leads to "porsasystem[.]com/js.php" to eventually take the victims to ClickFix-style pages for malware distribution. The findings illustrate the need for securing WordPress sites and ensuring that plugins, themes, and website software are kept up-to-date, enforcing strong passwords, scanning the sites for anomalies and unexpected administrator accounts created for maintaining persistent access even after the malware is detected and removed. Create ClickFix Pages Using IUAM ClickFix Generator The disclosure comes as Palo Alto Networks Unit 42 detailed a phishing kit named IUAM ClickFix Generator that allows attackers to infect users with malware by leveraging the ClickFix social engineering technique and come up with customizable landing pages by mimicking browser verification challenges often used to block automated traffic. "This tool allows threat actors to create highly customizable phishing pages that mimic the challenge-response behavior of a browser verification page commonly deployed by Content Delivery Networks (CDNs) and cloud security providers to defend against automated threats," security researcher Amer Elsad said. "The spoofed interface is designed to appear legitimate to victims, increasing the effectiveness of the lure." The bespoke phishing pages also come with capabilities to manipulate the clipboard, a crucial step in the ClickFix attack, as well as detect the operating system used in order to tailor the infection sequence and serve compatible malware. In at least two different cases, threat actors have been detected using pages generated using the kit to deploy information stealers such as DeerStealer and Odyssey Stealer, the latter of which is designed to target Apple macOS systems. The emergence of the IUAM ClickFix Generator adds to a prior alert from Microsoft warning of a rise in commercial ClickFix builders on underground forums since late 2024. Another notable example of a phishing kit that has integrated the offering is Impact Solutions. "The kits offer creation of landing pages with a variety of available lures, including Cloudflare," Microsoft noted back in August 2025. "They also offer construction of malicious commands that users will paste into the Windows Run dialog. These kits claim to guarantee antivirus and web protection bypass (some even promise that they can bypass Microsoft Defender SmartScreen), as well as payload persistence." It goes without saying that these tools further lower the barrier to entry for cybercriminals, enabling them to mount sophisticated, multi-platform attacks at scale without much effort or technical expertise. ClickFix Becomes Stealthy via Cache Smuggling The findings also follow the discovery of a new campaign that has innovated on the ClickFix attack formula by employing a sneaky technique referred to as cache smuggling to fly under the radar as opposed to explicitly downloading any malicious files on the target host. "This campaign differs from previous ClickFix variants in that the malicious script does not download any files or communicate with the internet," Expel Principal Threat Researcher Marcus Hutchins said. "This is achieved by using the browser's cache to pre-emptively store arbitrary data onto the user's machine." Expel said it was unable to determine the final payload received as part of the attack. It's also currently not known how users are redirected to the phishing page, and if it involves techniques like malvertising or search engine optimization (SEO) poisoning. In the attack documented by the cybersecurity company, the ClickFix-themed page masquerades as a Fortinet VPN Compliance Checker, using FileFix tactics to deceive users into launching the Windows File Explorer and pasting a malicious command into the address bar to trigger the execution of the payload. The invisible command is designed to run a PowerShell script via conhost.exe. What makes the script stand apart is that it does not download any additional malware or communicate with an attacker-controlled server. Instead, it executes an obfuscated payload that passes off as a JPEG image and is already cached by the browser when the user lands on the phishing page. "The file extracted from the cache is used to set up a scheduled task, which is set to run after each reboot," Hutchins told The Hacker News. "When the task runs, it connects to a command-and-control server waiting for follow-up commands." "Neither the web page nor the PowerShell script explicitly downloads any files," Hutchins explained. "By simply letting the browser cache the fake 'image,' the malware is able to get an entire ZIP file onto the local system without the PowerShell command needing to make any web requests." "The implications of this technique are concerning, as cache smuggling may offer a way to evade protections that would otherwise catch malicious files as they are downloaded and executed. An innocuous-looking 'image/jpeg' file is downloaded, only to have its contents extracted and then executed via a PowerShell command hidden in a ClickFix phishing lure." (The story was updated after publication to include additional insights from Expel.)
6 shared
Oct 8, 2025
From ClickFix to MetaStealer: Dissecting Evolving Threat Actor Techniques
By John Hammond, Alden Schmidt, Lindsey Welch During the past fifteen business days, Huntress analysts have observed increased threat activity involving several notable techniques. One case involved a malicious AnyDesk installer, which initially mimicked a standard ClickFix attack through a fake Cloudflare verification page but then utilized Windows File Explorer and an MSI package masked as a PDF to deploy MetaStealer malware. Additionally, two incidents involving the Cephalus ransomware variant were detected. This ransomware distinguishes itself by employing DLL sideloading through a legitimate SentinelOne executable, SentinelBrowserNativeHost.exe, to launch the payload. These recent findings highlight the ongoing evolution in threat actor tradecraft, combining established social engineering methods with more technically advanced infection chains and evasive deployment strategies. ClickFix attacks have been ticking up for over a year now, as attackers find success in tricking users into executing malicious code on their computers using CAPTCHA-based lures. We’ve seen quite a bit of these types of attacks on our end, but we’ve also seen threat actors adopting ClickFix-esque techniques in attacks that don’t follow the exact ClickFix playbook. Recently, our very own John Hammond received an email from someone who had come across a fake AnyDesk installer while searching for the AnyDesk remote tool. While early indicators of the attack look like it would turn into another ClickFix scam, a little bit of digging shows a unique infection chain that involves a fake Cloudflare Turnstile lure, the Windows search protocol, and an MSI package disguised as a PDF that cleverly grabs the victim’s hostname. The attack ultimately aims to drop MetaStealer, a commodity infostealer that’s been around since 2022 and is known for harvesting credentials and stealing files. ClickFix, FileFix, and other ‘fix’ variants First, a quick primer on the widely used ClickFix technique. The premise of ClickFix is that threat actors convince users to “fix” a purported issue, usually with a CAPTCHA on a webpage that they arrive on via a phishing message, or otherwise. The “solution” is copying and pasting a command fed to victims via an attacker-controlled prompt, which quietly kicks off the attack chain. While the classic ClickFix attack tricks users to paste and run commands in their Windows Run dialog box or via PowerShell, other variants of the attack have also sprung up that take a different approach. A few months ago, attackers turned to a similar technique, dubbed FileFix, which involves Windows File Explorer instead of the Run dialog box. We’ve seen a number of incidents that stem from ClickFix attacks. In the August 26 incident shown in Figure 1 below, for instance, we responded to an attack where a user executed a malicious command given to them via a fake Cloudflare Turnstile, which is Cloudflare’s verification tool meant to replace CAPTCHAs for weeding out bots. This then downloaded and installed an infostealer. Closer investigation revealed that the victim had visited the landing page teams-one[.]com. This page showed a Cloudflare Turnstile and marked the beginning stage of the ClickFix attack. Though there are similarities that we’ll outline below, the run-of-the-mill ClickFix incident demonstrated above differs significantly from the MetaStealer attack that we recently came across. Hacker tradecraft’s evolving daily, so let’s break it down on Tradecraft Tuesday! Join us monthly for an in-depth look at attacker tradecraft—no sales or product talk involved. Sign up for the series today or catch up on previous episodes. No tricks, just tradecraft. Register for Tradecraft Tuesday A ClickFix-turned-not-fix attack: what we saw The initial link for the fake AnyDesk installer redirects users to https[://]anydeesk[.]ink/download/anydesk[.]html, which displays a Cloudflare Turnstile - and a very questionable UI. The page purports to support “Secure Access Verification”, prompting the user to click a single button on the Cloudflare Turnstile to “verify you are human.” A quick look at the underlying HTML for the webpage (using View Source) is shrouded by obfuscated JavaScript, but that can be easily unraveled with JavaScript deobfuscation tools available in the browser tools console. This reveals the actual source code - and reveals the window.location.href value to be https[://]verification[.]anydeesk[.]ink/reCAPTCHA-v2[.]php. Up to this point, this has all the tell-tale signs of a ClickFix campaign: it involves a classic human verification social engineering piece, and sets the end user up to click on a box. However, when the victim clicks the box, the prompts in this attack lead to Windows File Explorer, Windows’ file management tool, as opposed to the Windows Run dialog box as we have seen with ClickFix. This is more indicative of a FileFix attack—but this attack still isn’t strictly FileFix, where victims are prodded to launch the address bar in Windows File Explorer (using a Ctrl+L and Ctrl+V combination to paste a PowerShell command that was automatically copied to their clipboard). Instead, in this attack, the PHP above redirects users to the Windows protocol handler (search-ms URI), a legitimate feature enabling applications to kick off specific search queries in Windows File Explorer. The specific Windows File Explorer “Search” redirect location can be seen in Figure 4 below, which displays the name for a custom search query as part of the search-ms URI protocol. As seen in Figure 5 below, Windows File Explorer then directs the victim to an attacker-controlled SMB share, essentially a remote file share allowing clients to access files on a remote server over a network. Here, victims are presented with a Windows shortcut LNK file – however, this LNK file is disguised as a PDF file called Readme Anydesk.pdf. Fake PDF lure: snagging victim hostnames As you can see below, the LNK file’s payload is: Once clicked, this file’s payload kicks off a few processes. Here, cmd.exe starts the automatic download of a legitimate AnyDesk installer on Microsoft Edge, possibly as a way to avoid suspicion for the victim. Meanwhile, it also begins a download for another purported “PDF,” which is downloaded from chat1[.]store and dropped into the temporary directory. Notably, this fake PDF is configured to grab the %COMPUTERNAME% environment variable as a subdomain. Subdomains don’t need to know the user’s hostname ahead of time, so this is a clever way for the attacker to nab that information from the victim. The fake PDF is then installed by msiexec (revealing that it’s actually an MSI package) and the cmd.exe process is then killed. Upon closer inspection of chat1[.]store (reached through a curl user agent), we can see everything from the MSI package, including files that would have been triggered as part of the attack chain. The two important files in the MSI package are a DLL (CustomActionDLL) and a CAB archive (Binary.bz.WrappedSetupProgram) which contains several other files. The CAB file contains two additional malicious files: 1.js which is responsible for cleaning up the infection chain, and ls26.exe which is the MetaStealer dropper. The MetaStealer file (ls26.exe) is a very large binary and is protected with Private EXE Protector. Upon further inspection, the executable reveals the same types of behavior that we’ve seen in known samples of MetaStealer, such as stealing from crypto wallets. ClickFix variants and lessons learned ClickFix, FileFix, and even this alternate-ClickFix attack we recently found show the power of blending social engineering with mundane processes, like CAPTCHAs or other verification tools. Additionally, these types of attacks that require some level of manual interaction from the victim, as they work to “fix” the purported broken process themselves, work in part because they can potentially circumvent security solutions. The guidance for organizations in regards to ClickFix has previously centered around taking measures like disallowing users to use the Windows Run dialog box if it’s not needed for everyday tasks. While this can be effective against traditional ClickFix attacks, the variants like the one above show that threat actors are continuing to move the needle in their infection chains, throwing a wrench into detection and prevention. Organizations should take additional measures, including educating users about the lures linked to ClickFix-like attacks. Users should be trained on spotting CAPTCHAs that prompt them to copy and paste into the Run dialog box, or redirect to Windows File Explorer. Maintain Situational Awareness—Register for Tradecraft Tuesday Tradecraft Tuesday provides cybersecurity professionals with an in-depth analysis of the latest threat actors, attack vectors, and mitigation strategies. Each weekly session features technical walkthroughs of recent incidents, comprehensive breakdowns of malware trends, and up-to-date indicators of compromise (IOCs). Participants gain: Detailed briefings on emerging threat campaigns and ransomware variants Evidence-driven defense methodologies and remediation techniques Direct interaction with Huntress analysts for incident response insights Access to actionable threat intelligence and detection guidance Advance your defensive posture with real-time intelligence and technical education specifically designed for those responsible for safeguarding their organization’s environment. IOCs Sponsored and written by Huntress.
6 shared
Sep 23, 2025