Formula 1 Phishing Campaign & Kit Analysis

SOCRadar Threat Research Unit (STRU) has identified and analyzed a sophisticated, multi-stage phishing campaign that exploits the high-intensity demand for Formula 1 Grand Prix tickets. The attackers use highly convincing replicas of official ticketing platforms to deceive victims, tricking them into providing payment information and two-factor authentication (2FA) tokens. The operation allows attackers to engage in real-time, operator-controlled social engineering, adapting their tactics to bypass multi-factor authentication (MFA) measures.

This article details the infrastructure and operational methods of a malicious network currently targeting high-profile Formula 1 events.

Key Findings

• Expansive Infrastructure: The campaign is orchestrated across a network of at least 11 domains impersonating Singapore and Spanish Grand Prix events, all sharing a unified backend hosting structure.
• Scale of Deception: The attackers have mirrored the entire architecture of the legitimate sites, creating a 134-page repository of content – including news, event info, and rules to bypass casual inspection.
• Live Backend Control: The backend comprises 40 distinct PHP files designed for real-time human interaction. This allows operators to dynamically inject verification screens tailored to the victim’s specific bank.
• Precision Targeting: The system utilizes credit card BINs to identify the victim’s bank, enabling the delivery of branded, customized phishing interfaces for 8 major institutions, including Emirates NBD, RAKBANK, and HSBC.

Formula 1 Phishing Campaign: Background & Threat Context

Phishing lures heavily benefit from the unique retail conditions surrounding Formula 1 race weekends. These events create a brief, high-intensity ticket purchasing window where authentic buyers are primed to act rapidly, commit large sums of money – with hospitality packages on this specific kit’s price list reaching thousands of Singapore dollars – and tolerate unfamiliar payment steps.

This analysis originates from a broader initiative to track a cluster of lookalike Formula 1 ticketing platforms rather than a single isolated event. Within this cluster, f1-tickets-sg[.]com represents an entry where exposure in its hosting configuration enabled the complete recovery of the kit’s underlying source code, moving beyond just its rendered pages. As a result, this domain serves as a source-code representative for the campaign’s shared infrastructure, rather than necessarily being its most active operational hub.

Related Cluster: Regional Grand Prix Lookalikes

A cluster of eleven domains follows a uniform naming convention mirroring f1-tickets-sg[.]com, where “f1” and “ticket(s)” or “booking” are combined with a geographical suffix. Ten of these sites specifically impersonate the official “Gran Premio de España” (Spanish GP, Madrid) web page and share an identical hosting class; furthermore, automated detection tools have already assigned malicious-content verdicts to multiple entries within this group:

Additional evidence further substantiates the connection to the examined kit: the request log for f1-tickets-spain[.]com incorporates mc[.]yandex[.]ru/metrika/tag.js (Yandex Metrika, a Russian analytics platform). This aligns seamlessly with the Russian-language comments discovered within the kit’s own main.py cloning script. Furthermore, these domains exhibit a naming pattern that closely matches the domain from which the kit was originally sourced, reinforcing that this entire cluster is tied to the analyzed infrastructure.

Kit Architecture & Cloning Technique

The phishing storefront achieves high-fidelity duplication of the legitimate Singapore GP ticketing platform, accurately mimicking its layout, bigtix-* CSS classes, navigation links (Tickets, Hospitality, Entertainment, News, FAQ, Event Info), and official 15-page Terms & Conditions PDF.

The creation of this replica is driven by an integrated cloning utility discovered at booking/main.py. This Python-based scraper, which features Russian-language comments, systematically parses the targeted HTML hierarchy to identify and harvest remote asset URLs. It then downloads these files locally and rewrites the HTML code to point to the newly localized copies.

Page Inventory

The mirror runs to 134 HTML pages, closely tracking the real site’s own information architecture rather than a stripped-down single-page lure. The scale itself is evidence of how much effort went into making the storefront pass casual inspection:

Endpoint Inventory

Behind the storefront sit 40 PHP files, split cleanly between checkout plumbing and the fraud-verification module. The latter alone accounts for two-thirds of the backend:

Attack Flow of Formula 1 Phishing Campaign

The checkout is implemented as a sequence of small, disposable PHP endpoints – deliberately unremarkable, because looking exactly like a normal checkout is the point.

1. Ticket Selection

In this stage, the site mimics a legitimate checkout, allowing users to select ticket categories, quantities, and dates. Behind the scenes, the kit extracts venue and pricing data from the mirrored catalog pages, storing selections in $_SESSION via booking/quantity.php and vendor/quantity.php, while enforcing a strict purchase limit (1 to 9 tickets).

2. Patron Details

The booking/details.php file presents a “Patron Information” form designed to collect the user’s full name, email address, phone number, billing address, and an exact replica of the original site’s ISO country list. This form submits the gathered information to vendor/details.php. The targeted endpoint does not validate the input data other than confirming that the required fields are filled; its primary role is to temporarily store the information in the session cache before the user is routed to the payment phase.

3. Card Capture

Designed to replicate a legitimate checkout experience, booking/booking/payment.php presents a card data collection form (capturing card number, expiry date, and CVV) that displays the victim’s actual, live cart total. Because the displayed transaction amount is accurate, it successfully establishes credibility for the subsequent phase of the attack.

4. Exfiltration

Form data is transmitted to booking/api.php, which filters and isolates specific high-value fields, appends the victim’s User-Agent and IP address, and relays the record as a JSON payload to a remote server. The server’s response issues a session token via a cookie, effectively tying all subsequent actions to that specific victim record on the operator’s infrastructure.

4. Bank-Specific Challenge

The core script secure_check/index.php retrieves the compromised card number from a cookie, determines the issuing financial institution via the card’s BIN, and generates a fraudulent, bank-specific 3-D Secure or OTP (one-time password) authentication page. Concurrently, the attacker controls the operation through a polling endpoint, dynamically selecting the specific verification interface (such as OTP, balance checks, push notifications, or identity requests) presented to the victim in real time.

Command-and-Control & Exfiltration

Dynamic Two-Way Relay Architecture

Rather than simply exfiltrating stolen information, api.php enables an action=get request to /api/record/step, which allows the front-end interface to query the command-and-control server for the next display sequence.

This bidirectional communication indicates the use of a manned or semi-automated fraud panel. It allows an attacker to actively monitor incoming payment card data, anticipate the issuing financial institution’s legitimate challenge, and deliver a corresponding fraudulent interface to the target in real time.

BIN-Based Bank Routing

When a paid lookup key is active, the routing mechanism analyzes the first six digits (the BIN) of the captured card. It then identifies the issuing financial institution through an external BIN API to automatically choose the corresponding bank-branded interface:

The phishing kit pre-configures dedicated branding, complete with unique stylesheets, logos, and tailored challenge copy, for eight specific financial institutions:

• Abu Dhabi Commercial Bank
• Dubai Islamic Bank
• Emirates Islamic
• Emirates NBD
• First Abu Dhabi Bank
• HSBC
• Mashreq
• RAKBank

Within the recovered build, the BIN lookup mechanism is turned off and the API key is left unconfigured. Consequently, even though the branded components are fully integrated, this specific instance defaults to a standardized, generic verification screen. This pattern indicates that the domain could be a template currently undergoing configuration, or that these assets are actively serving other, more remote nodes involved in the same campaign.

Victimology & Targeting

This phishing campaign exploits the high-intensity demand for Formula 1 Grand Prix tickets, focusing on high-value targets seeking premium hospitality and grandstand packages. By leveraging the inherent urgency and scarcity of ticket sales, the attackers manipulate victims into compromising substantial financial transactions.

The targeting strategy is highly specific, primarily focusing on customers of major financial institutions in the Middle East region. The phishing kit includes hardcoded assets and branded verification interfaces for institutions such as Emirates NBD, RAKBANK, and HSBC. This precision targeting allows attackers to present victims with a familiar and trusted authentication environment, significantly increasing the probability of successful 2FA bypass and credential harvesting.

Recommendations

• For Security Operations Centers (SOC): Immediately block the identified C2 infrastructure at 144.31.3[.]209 and the listed domain cluster. Monitor internal traffic for any references to these specific phishing domains.
• Proactive Threat Hunting: Monitor for the registration of new domains following the f1-[ticket|booking]-[region|city] naming convention, as this pattern is a reliable indicator of further campaign expansion.
• User Awareness & Education: Organizations should advise employees purchasing event tickets to strictly verify the URL against official Formula 1 channels. Emphasize that legitimate ticketing platforms will never request OTP codes, 2FA push approvals, or “card balance” verification for transaction completion.
• Financial Institution Vigilance: Implement specific fraud detection triggers for “balance check” or “push notification” authorization flows that originate from non-partnered, high-risk merchant domains.

Conclusion

This Formula 1 phishing campaign marks a major shift from standard, automated kits to a live-operated “Phishing-as-a-Service” (PhaaS) model, where human operators actively manage fraud in real time. By precisely replicating 134 pages of authentic content, the adversaries have established a storefront that significantly reduces the friction required for successful fraud, while dynamic, BIN-based routing enables them to adjust social engineering lures on the fly to circumvent complex 2FA security controls.

The implications of this shift are profound:

• Rather than functioning as a static phishing kit, this represents a dynamic operation where human operators actively engage with victims in real time.
• Consequently, traditional phishing detection methods become significantly less effective.
• This human-in-the-loop approach drastically increases conversion rates as banking workflows are dynamically adapted to the victim.

Because of this persistent and multi-layered infrastructure, relying on static blacklists is no longer sufficient; organizations must deploy proactive, behavior-based monitoring strategies to counter these advanced threats.

Indicators of Compromise (IOCs)