Introduction

Phishing remains a significant threat in 2025, causing severe financial and reputational damage to businesses and organizations. In 2024, Group-IB identified more than 80,000 phishing websites—a 22% increase compared to 2023—according to the  High-Tech Crime Trends Report 2025.

Most recently, Group-IB uncovered a phishing campaign targeting a toll road service provider. We believe this campaign began in late 2023, as some domains associated with the attack were delivered to users during that period.

To better understand this threat, our analysts examined how the scammers processes victim data, verifies input, and protects the phishing websites from detection and analysis. In this ongoing campaign, the scammers integrate third-party JavaScript libraries to streamline data collection and real-time validation. By studying the technical flow and backend logic, we uncover how this group filters access, tracks user sessions, and limits visibility of the phishing content to targeted victims—effectively complicating efforts by researchers and automated scanners to analyze the page.

Key discoveries in the blog

  • Group-IB researchers uncovered a highly coordinated phishing campaign in which scammers leveraged third-party JavaScript libraries such as FingerprintJS and Cleave.js to evade detection and verify input data in real time.
  • While techniques such as user input validation and victim selection based on IP, region, or language are commonly used by threat actors, this campaign stands out by incorporating browser fingerprinting as an additional layer of control. This approach helps restrict access to targeted victims while simultaneously complicating analysis by researchers and automated tools.
  • As of this writing, the phishing campaign remains active, with threat actors continuously generating and distributing new malicious links to unsuspecting victims.

Who may find this blog interesting:

  • Cybersecurity analysts and corporate security teams
  • Cyber investigators
  • Computer Emergency Response Teams (CERT)
  • Law enforcement investigators
  • Cyber police forces
  • Businesses
Figure 1. Diagram illustrating the workflow of a toll road impersonation phishing campaign.

Figure 1. Diagram illustrating the workflow of a toll road impersonation phishing campaign.

Phishy Package

Group-IB recently identified an SMS phishing campaign in which  cybercriminals impersonate a toll road service provider  in order to deceive unsuspecting users. Within the message, the cybercriminals attempt to deceive victims by claiming that they must pay outstanding toll fees before a deadline to avoid penalties (“et éviter des pénalités”).

As is common in most phishing attempts, the cybercriminals introduce a sense of urgency, warning victims of significant late fees if they fail to act promptly. To complete the supposed payment, victims are directed to a fraudulent website designed to steal their payment information.

The cybercriminals have conducted thorough research on their victims, adapting the language of the phishing messages in French, the main language used in the specific region of Canada being targeted. By localizing their messaging and tactics, they add a layer of credibility to their phishing techniques, making it more convincing and increasing the likelihood that victims will fall for the scam.

As part of the phishing campaign, cybercriminals distribute fraudulent SMS messages to a wide range of victims using bulk messaging techniques.

Figure 2. Examples of scam SMS messages sent to victims.

Figure 2. Examples of scam SMS messages sent to victims.

These phishing messages are often sent from spoofed local or international phone numbers, making them appear legitimate to recipients. Recently, Group-IB published a study on  SMS pumping abuse, which sheds light on how attackers exploit misconfigured SMS gateways and commercial application-to-person (A2P) messaging platforms to automate and scale SMS distribution.

As soon as the victims click on the link, they are directed to a phishing website which is almost indistinguishable from the legitimate website of the toll road service provider.

Figure 3. A screenshot of the phishing website mimicking the legitimate toll service portal.

Figure 3. A screenshot of the phishing website mimicking the legitimate toll service portal.

After clicking the “Payer maintenant” (Pay Now)  button, victims are prompted to enter personal information, including their name, date of birth, phone number, and residential address. Cybercriminals then harvest this data, potentially using it for future phishing attacks or other fraudulent activities

Figure 4. A screenshot of the form on the phishing website designed to capture victims’ personal information.

Figure 4. A screenshot of the form on the phishing website designed to capture victims’ personal information.

After entering their personal information, users are redirected to another fraudulent webpage where they are prompted to provide their payment card details, including card number, expiration date, and CVV code.

Figure 5. A screenshot of the fake checkout page used to steal bank card information.

Figure 5. A screenshot of the fake checkout page used to steal bank card information.

By early 2025, cybercriminals have evolved their phishing tactics by exploiting trusted services like Google Accelerated Mobile Pages (AMP), which are optimized for mobile browsing experiences. Instead of sending phishing links directly, attackers now use multiple layers of redirection through legitimate domains—such as Google’s URL redirection service—to evade detection. This method effectively bypasses security mechanisms that rely on domain reputation, while leveraging users’ trust in reputable platforms. As a result, phishing campaigns have become more elusive, making it significantly harder for automated security filters to detect and block malicious activity. This multi-layered redirection technique, including the use of Google AMP and encoded parameters to cloak phishing URLs, was also documented in our previous research Trust Hijacked.

In the example below, the phishing URL is masked within a Google AMP link.

Figure 6. Screenshots of the masked phishing link delivered via SMS using Google AMP redirect (left), and the redirect notice on the browser (right).

Figure 6. Screenshots of the masked phishing link delivered via SMS using Google AMP redirect (left), and the redirect notice on the browser (right).

Uncovering the Phishing Campaign

Several phishing domain names identified in the campaign were uncovered through the Threat Intelligence capabilities of Group-IB’s Unified Risk Platform (URP). An example of how the phishing campaign’s resources are interconnected is provided in the below screenshot from Group-IB’s Graph, a patented technology across URP’s modules.

 

Figure 7. Group-IB’s Graph, which maps the malicious infrastructure behind the phishing campaign.

Figure 7. Group-IB’s Graph, which maps the malicious infrastructure behind the phishing campaign.

In the example shown above, while observing some phishing domains, Group-IB’s Graph reveals a connection between them and the email address ra<redacted characters>@fuwamofu.com—a temporary email address generated from a free mail service—in the DNS Start of Authority (SOA) records. By analyzing domains that share the same email address in the SOA records, we identified additional related domains linked to the campaign.

Figure 8. SOA Record analysis reveals the cybercriminal’s temporary email address.

Figure 8. SOA Record analysis reveals the cybercriminal’s temporary email address.

Figure 9. A list of domains with matching SOA records, detected by Group-IB Graph.

Figure 9. A list of domains with matching SOA records, detected by Group-IB Graph.

Exploiting Third-Party JavaScript for Evasion and Data Verification

While examining the source code of one of the phishing pages, we identified that scammers have been leveraging FingerprintJS, a third-party browser fingerprinting service, to identify and track users’ devices and browsers. This technique serves a dual purpose: not only does it help tailor access to specific victims, but it also acts as a layer of protection against detection and analysis by security researchers and automated scanning tools.

Even if a user attempts to mask their identity using a VPN, access to the phishing content is denied unless the browser and user-agent match the expected Fingerprint parameters. This ensures that only selected users are granted access, while others—including researchers and automated services like VirusTotal or urlscan.io—are blocked and shown an “Access Denied” message.

Figure 10. Advanced evasion technique using FingerprintJS to block non-targeted users.

Figure 10. Advanced evasion technique using FingerprintJS to block non-targeted users.

This React component (App.js) implements device fingerprint verification using FingerprintJS Pro to determine whether a visitor is legitimate. The component integrates real-time device fingerprinting with an authentication system to verify user access before allowing them into the application.

The app uses the useVisitorData hook from the FingerprintJS Pro React SDK to fetch fingerprinting data as soon as the component is mounted. This data includes unique identifiers derived from the visitor’s browser and device. The function returns an object containing isLoading, error, and data.

FingerprintJS is an advanced browser fingerprinting library designed to identify and track users based on unique device and browser characteristics. It collects various data points—such as user agent, screen resolution, installed fonts, and time zone—to generate a unique visitor ID. This identifier helps websites detect fraud, prevent unauthorized access, and analyze user behavior without relying on cookies.

FingerprintJS is commonly used for:

  • Fraud Detection: Identifying suspicious or repeated login attempts.
  • User Authentication: Providing an extra security layer by verifying device consistency.
  • Personalization: Recognizing returning users for tailored experiences.

The app utilizes Proxy Integration for the Fingerprint Server API, routing requests through its own domain, api.lillliiilllliiiiilliilllllllliiii.site, instead of connecting directly to Fingerprint’s servers.

Figure 11. An example of routing FingerprintJS API requests through a custom domain.

Figure 11. An example of routing FingerprintJS API requests through a custom domain.

The screenshot below shows a FingerprintJS agent identification request from the user’s browser to the Fingerprint Server API hosted in its own domain. Body fields may include fingerprint data — all turned into compact strings that aren’t meant to be human-readable. Unreadable text just means the FingerprintJS agent, possibly encrypted — gathering detailed device information in a lightweight, tamper-resistant way before sending it to the FingerprintJS server for processing.

Figure 12. Transmission of encrypted fingerprint data via FingerprintJS Server API.

Figure 12. Transmission of encrypted fingerprint data via FingerprintJS Server API.

User Identification via Fingerprinting

The requestId represents the unique request ID associated with this machine fingerprint. It identifies that the fingerprint was generated by this app and is stored in the backend for tracking and verification purposes.

Figure 13. Client-Side logic for submitting fingerprint request ID to backend API.

Figure 13. Client-Side logic for submitting fingerprint request ID to backend API.

Once fingerprint data is available, an effect (useEffect) runs and checks whether requestId exists in the response. If it does, the app sends an HTTP POST request to the backend (/api/verify-fingerprint) with the requestId. This request is essential for verifying the authenticity of the fingerprint and determining whether the user should be granted access. All blocking logic is handled on the backend.

Figure 14. Fingerprint verification and access control based on backend response.

Figure 14. Fingerprint verification and access control based on backend response.

If the server responds with “Verification Successful”, the status updates to “success”, and a redirect occurs to the homepage (‘/’) after a brief delay to ensure session cookies are set correctly. These cookies are then used by the app to identify and recognize verified users in subsequent sessions.

Figure 15. Phishing page with embedded JavaScript for session handling and data exfiltration.

Figure 15. Phishing page with embedded JavaScript for session handling and data exfiltration.

If verification fails, the status updates to “failed”, an error message is logged, and access is denied, preventing the user from accessing the content. If an error occurs, such as network issues, the state updates to “error” similarly restricting access to the content until the issue is resolved.

Figure 16. Access Control Logic Based on Fingerprint Verification Status


Figure 16. Access Control Logic Based on Fingerprint Verification Status

In the screenshots below, we see the reasons for the failed verification.

Example 1: VPN detected.

Figure 17. Failed verification from Custom Server Authorization.

Figure 17. Failed verification from Custom Server Authorization.

Example 2: Datacenter IP detected

Figure 18. Continuous loading if verification failed.

Figure 18. Continuous loading if verification failed.

In the background, Custom Authorization responded, “VPN detected” or “Datacenter IP detected” indicating that these checks are likely intended to prevent analysis by researchers and automated scanning tools.

Figure 19. Failed verification reason Unknown Datacenter.

Figure 19. Failed verification reason Unknown Datacenter.

Analysing the Fingerprint JS Library

Group-IB analysts have accessed the official Fingerprint website and conducted an analysis of its functionality. The platform allows for the collection of fingerprint data from various browser configurations, enabling a comparative assessment of differences. This approach provides deeper insights into the app’s blocking logic and how it identifies and differentiates users.

The output from the FingerprintJS library below shows that it collects various data from our machine, including information related to  VPN, datacenter, auxiliary mobile devices, bot detection, proxy usage, IP reputation, and more. Website owners can use this data to create own blocking logic

Figure 20. Fingerprint JSON file from the official Fingerprint website.

Figure 20. Fingerprint JSON file from the official Fingerprint website.

Analyzing Custom Backend Authorization

During our analysis of the backend’s authentication mechanism, we compared both failed and successful verification attempts. We observed that the backend checks the Cookie field for a specific value during the authorization process. Notably, setting the cookie to verified=true was enough to bypass the custom verification logic. By manually injecting this cookie into the request headers, we were able to gain unauthorized access and bypass the intended verification process.

Figure 21a. Before editing the cookie field.

Figure 21a. Before editing the cookie field.

Figure 21b. After editing the cookie field to “verified=true”.

Figure 21b. After editing the cookie field to “verified=true”.

Sending Heartbeat and User’s Input Data

User data is continuously collected and sent to the backend in the background due to the setInterval function, which repeatedly triggers the sendHeartbeatData() function every 3 seconds. This function gathers session-related details, including sessionAuth, the current page, and the user agent, and then sends them to the endpoint /api/log-heartbeat. The following code ensures that this process runs indefinitely as long as the page remains open:

Figure 22. Initialization of heartbeat and typing detection intervals

Figure 22. Initialization of heartbeat and typing detection intervals

Inside sendHeartbeatData(), the collected session data is structured into a payload and sent to the server:

Figure 23. sendHeartbeatData() and flushInputData(): Sending session and user input data to the server

Figure 23. sendHeartbeatData() and flushInputData(): Sending session and user input data to the server

Because setInterval ensures that sendHeartbeatData() executes every 3 seconds, session data is repeatedly collected and logged, leading to the continuous appearance of sessionAuth in the console logs.

Additionally, sendInputData captures the browser’s user agent, session UUID, current path, and user inputs within text areas. It utilizes EventListeners to log and transmit data after every user input, keydown and autofill ensuring real-time tracking of interactions.

Figure 24. A screenshot of the sendInputDatafunction.

Figure 24. A screenshot of the sendInputDatafunction.

Figure 25. Send partial input data in request from Personal Page.

Figure 25. Send partial input data in request from Personal Page.

Figure 26. Send input data from Personal Page.

Figure 26. Send input data from Personal Page.

Figure 27. Send input data from Card Page.

Figure 27. Send input data from Card Page.

Custom Input Validation

To verify the data entered by their victims, scammers use Custom Validation and Cleave.js.

Cleave.js a JavaScript library designed for input formatting. The provided JavaScript code initializes Cleave.js input masks for specific input fields based on their data-format attributes, ensuring that user input follows predefined patterns. CleaveJS is used to validate data for sending inputs received from autofill to the backend (see sendInputData). Custom validation used only for user form when user clicks a button.

Figure 28. Custom validation and input masking with Cleave.js for form submission

Figure 28. Custom validation and input masking with Cleave.js for form submission

Cleave.js is a lightweight JavaScript library that helps format user input in real time. It dynamically applies formatting as users type, making input fields more structured and user-friendly. It is commonly used for:

  •         Phone number formatting (e.g., +1 (123) 456-7890)
  •         Credit card formatting (e.g., 1234 5678 9012 3456)
  •         Date formatting (e.g., MM/DD/YYYY)
  •         Custom input masks for structured data entry

The JavaScript code is responsible for initializing Cleave.js and applying input masks dynamically to relevant input fields. The script begins by checking whether Cleave.js is properly loaded to prevent runtime errors. To avoid redundant initializations, it maintains a Set called initializedInputs, which keeps track of input elements that have already been processed. It then selects all input elements that contain the data-format attribute and iterates through them to determine their intended formatting.

For input fields designated as phone numbers (data-format=”phone”), the script further checks for an optional attribute, data-phone-format-mode, which determines whether to use a specific region code (specify-region) or rely on automatic country detection (auto-detect). If a specific region is provided through data-region-code, Cleave.js formats the phone number according to the rules of that country. Otherwise, Cleave.js attempts to detect the region automatically, allowing for flexible input handling.

For credit card fields (data-format=”credit-card”), Cleave.js is initialized with a setting that correctly spaces out the numbers based on standard credit card formatting. This ensures that users enter card numbers in a structured manner, preventing common mistakes such as missing digits or incorrect grouping.

The script also supports custom input formats through the data-format=”custom” attribute. When this option is detected, the script retrieves the format pattern from data-custom-format and processes it into a set of blocks and delimiters. In this process, numerical placeholders (9) are counted and grouped into blocks, while non-numeric characters are treated as delimiters. This allows Cleave.js to dynamically apply formatting rules that fit custom patterns, such as serial numbers or unique ID formats. Finally, Cleave.js is initialized with the extracted blocks and delimiters, ensuring that only numeric input is permitted while enforcing the intended format.

Figure 29. Cleave input data validation

Figure 29. Cleave input data validation

This JavaScript code ensures input fields comply with specific validation rules using Cleave.js for numeric input and an event listener for letter-only input. It first selects all inputs with the data-validation attribute and iterates over them. If the validation type is “digits”, Cleave.js is initialized with numericOnly: true, restricting input to numbers. If the validation type is “letters”, an event listener removes any non-alphabetic characters in real time. To prevent duplicate processing, inputs are tracked in the initializedInputs set.

If Cleave.js is not loaded, the script logs an error: “Cleave.js is not loaded. Input formatting will not work.” This prevents unexpected behavior and alerts developers to potential issues.

Figure 30. Payment custom form validation

Figure 30. Payment custom form validation

The credit card number is checked using the Luhn algorithm, a mathematical formula that detects errors in card numbers. Any spaces entered by the user are removed before processing. If the number does not pass the Luhn check, it is considered invalid. For example, card numbers like 4111 1111 1111 1111 (Visa) and 5555 5555 5555 4444 (Mastercard) are valid, whereas 1234 5678 9012 3456 would be rejected.

The expiration date must be in the MM/YY format and represent a future date. The validation process ensures that the month (MM) is between 01 and 12, and that the card has not already expired. If the provided year is lower than the current year, the system assumes it refers to the next century. For example, 04/26 (April 2026) is valid, but 13/25 (invalid month) or 03/21 (expired card) would be rejected.

Lastly, the CVV (Card Verification Value) is checked to ensure it consists of only 3 or 4 digits, depending on the card type. Visa, Mastercard, and Discover use a 3-digit CVV, while American Express requires 4 digits. Invalid CVVs containing letters or exceeding the allowed length, such as 12A or 12345, will be rejected.

Scammers exploit third-party JavaScript libraries instead of writing malicious code from scratch, allowing them to create fraudulent websites with minimal effort while evading detection. By leveraging well-established tools like Cleave.js for input formatting or FingerprintJS for device tracking, scammers can integrate sophisticated functionalities into their fake sites without raising suspicion. These libraries, originally designed for legitimate purposes, help cybercriminals mimic real authentication processes, validate user input, and even track session behavior—making their scams appear more credible. This strategy not only saves them time but also allows them to bypass basic security checks, as security systems often trust widely used third-party scripts.

Conclusion

The world remains in the grip of a scam epidemic, with cybercriminals constantly refining their techniques to deceive victims and bypass security measures. From sophisticated phishing schemes to the abuse of trusted services, attackers continuously evolve to evade detection and exploit human vulnerabilities.

What makes these threats even more concerning is their adaptability. Scammers can tailor their methods to target companies across different industries and regions, adjusting their tactics based on the victim profile and scam context. This flexibility allows them to exploit a wide range of vulnerabilities, making no organization or individual immune to their attacks.

In this ever-changing threat landscape, vigilance and proactive education are more critical than ever. Raising awareness about emerging scam tactics, maintaining strong digital hygiene, and fostering skepticism toward unsolicited messages are essential in mitigating risks. By staying informed and cautious, individuals and organizations can strengthen their defenses and reduce the likelihood of falling victim to these increasingly sophisticated cyber threats.

Recommendations for users

  1. Strong digital hygiene practices and user vigilance are crucial in preventing phishing attacks. We strongly advise users to be cautious when clicking on links received via SMS from unknown sources. We urge users to interact with links only from official resources.
  2. Always scrutinize the domain names when presented with links relating to companies shared in messaging apps. Scammers usually use domain names that look similar to existing brand names as part of their efforts to trick users into entering sensitive data.
  3. Always verify the URL prior to providing any confidential data and payment card details on trusted websites. Before entering your payment information, users can perform a Google search to check the site’s creation date. If the website is only a few months old, it is likely a scam or phishing page. Always trust official, verified websites.

Recommendations for Companies

  1. Companies should proactively educate their customers on how to distinguish between scam resources and legitimate ones. Therefore, when identifying such scam campaigns, it is advisable to promptly share this information on the official website or through customer email communication.
  2. To prevent the illegal use of your intellectual property assets, use Digital Risk Protection solutions that help promptly detect threats to a specific brand in the digital space and then send them for blocking. These solutions can also issue proactive takedowns to stop new scams before they begin operating.
  3. Leverage advanced Threat Intelligence solutions to be constantly up-to-date with the new schemes and tools that cybercriminals use, so you can proactively respond to them and/or inform and educate your customers.
  4. Conduct investigations into brand abuse and scam cases in order to identify the threat actors, and collect valuable evidence that can be used to take a legal action against the threat actors.
  5. If you or your company become victims of frauhttps://www.group-ib.com/products/digital-risk-protection/d, immediately contact your local law enforcement agency and notify the technical support team of the website involved. You can also report fraud to CERT-GIB 24/7 by visiting our website or emailing response@cert-gib.com.

 

Frequently Asked Questions

1. What is the toll phishing phishing campaign?
The toll phishing is a sophisticated phishing campaign discovered by Group-IB targeting users of a toll road service provider. It leverages advanced evasion techniques, such as third-party JavaScript libraries, fake payment portals, and localized SMS messages to steal personal and financial information.

2. How do scammers trick victims in this phishing campaign?
Scammers impersonate a legitimate toll service provider and send SMS messages claiming that recipients owe toll fees. These messages include fraudulent links leading to fake websites that closely mimic the real toll service portal, where users are prompted to submit sensitive data and payment information.

3. What makes this phishing campaign different from typical scams?
This campaign combines multiple sophisticated tactics, including:

  • Browser fingerprinting using FingerprintJS to block unwanted access.
  • Streamline data collection and real-time validation
  • Multi-layered URL redirection through trusted services like Google AMP to bypass detection.
  • Localized content tailored in the victim’s native language for greater credibility.

4. How does FingerprintJS help scammers evade detection?
FingerprintJS generates unique fingerprints based on the user browser and device. If the fingerprint doesn’t match the scammer’s criteria, access is denied. This not only limits the phishing content to targeted victims but also prevents analysis by researchers and tools like urlscan.io or VirusTotal by blocking traffic from VPNs and datacenter IPs, helping the scam avoid detection.

5. What role does Cleave.js play in the attack?
Cleave.js is a JavaScript library used to format and validate user input in real time. Scammers exploit this tool to ensure victims enter personal and payment data in the correct format, enhancing the scam’s credibility and data quality.

6. How are phishing links being disguised?
Phishing URLs are masked using legitimate redirection platforms like Google AMP. Instead of sending a direct malicious link, scammers embed the phishing URL within a Google redirect to evade security filters and exploit user trust in well-known platforms.

7. Who is most at risk from these phishing campaigns?
Organizations and individuals in regions where toll road services are common, particularly those receiving SMS-based alerts, are primary targets. Cybersecurity professionals, CERT teams, law enforcement, and businesses concerned with digital fraud should be aware of these evolving threats.

8. What should users do to protect themselves from phishing attacks like this?
Avoid clicking on links from unknown SMS messages, and always verify the website’s URL before providing any personal or confidential information.

9. What can companies do to defend against such scams?
Educate customers on identifying phishing attempts and implement Digital Risk Protection solutions to detect and take down fraudulent domains. Companies should also monitor for unauthorized use of branding and logos and employ Threat Intelligence tools to stay updated on new scams and cybercriminal tools.