We Followed a Fake FRSC Payment Website. Here's What It Did With Card Data

Our cybersecurity team traced a fake traffic-fine portal from the first click to the payment page. It was collecting card data field by field, profiling each card on a remote server, and was built to ask for your OTP.

A fake traffic fine works because it starts with something ordinary.

A motorist gets a message about a vehicle offence. A link offers a quick way to check it and settle a small payment. The page looks official, the language sounds bureaucratic, and the Federal Road Safety Corps (FRSC) name is everywhere.

Then comes the payment page. That is where the real danger begins.

After public warnings about websites impersonating the FRSC, we examined a captured copy of one of these portals. Using synthetic test data, we recorded exactly what the browser sent and received as a visitor moved from vehicle check to payment.

The short version: this was not a fake page showing a fake fine. It was a live application, reporting what visitors typed to a remote server as they typed it.

The fine is just the bait

The site never opens by asking for a bank password. It builds a story first.

It asks for a vehicle plate number. Then it shows an alleged offence, a fine, a deadline and an amount. Each step makes the next request feel more reasonable.

By the time the card form appears, paying feels like the natural end of a routine government process. The network traffic tells a different story.

Your card left the browser before you pressed Pay

The site kept a live WebSocket connection open to a remote server, bm[.]ybwx[.]eu[.]cc, and also exchanged API calls with it. The server resolved to 43[.]157[.]155[.]231 and identified itself as a GoFrame HTTP Server behind Caddy.

Where it was hosted matters less than what it sent there.

The form did not wait for a final submit. Each field was transmitted as it was filled in, as a separate event:

• Card number

• Expiry date

• CVV

• Cardholder name

A separate submit_card event then sent the complete card record.

A victim does not need to finish a payment for their card details to be gone. The data had already left the browser.

data flow · fake FRSC portal, 5 stages

The server was grading each card

After submission, the server sent back a profile of the card: BIN, issuing bank, country, network, card type and card level. The response also carried a cardHistory record tied to that submission.

In other words, the backend was not just storing numbers. It was assessing what kind of card it had received.

Our test card was rejected with a message asking the visitor to use a different card. That points strongly to card qualification logic running on the attacker's server.

What this does not show: that any real account was debited. The test proves collection and processing, not a completed theft.

It was built to ask for your OTP

The source code includes a full OTP stage. It can display an OTP box, submit the code, resend it, handle success and failure, and pass the code back to the server over the same WebSocket channel.

So the site was designed to collect one-time passwords. But our test session did not capture a real victim's OTP, and we cannot claim one was relayed to an attacker.

The capability is there. The full chain from OTP to money lost was not reproduced. Good investigation means making the strongest claim the evidence supports, not the most dramatic one.

A loading screen is not a payment

After the card form, the site plays a convincing processing sequence: "Encrypting card information", "Checking fraud risk", "Waiting for bank authorization", and more.

None of it comes from a bank. The steps run on timers in the page itself, and the transaction ID is generated locally in the browser. It is theatre, designed to make the visitor believe a real payment processor is at work.

The lesson for anyone investigating phishing: a progress bar proves nothing. Network traffic does.

What about the ₦300?

The site has a configurable pay_amount, with a fallback of ₦300 when none is set. That matters because public reports on the wider fake-FRSC campaign describe small first charges followed by much larger unauthorised debits.

But our captured session did not show that pattern. We did not observe a ₦300 charge, a larger follow-up charge, a balance check, or any completed payment. We also found no link to a known payment gateway such as Paystack, Flutterwave, Interswitch or Moniepoint.

Those questions remain open.

The fake site can send you to the real one

Under certain conditions, the application redirects visitors to the genuine FRSC website.

That sounds harmless. It isn't. Landing on a real government domain at the end of the journey makes everything before it feel legitimate.

The backend controls this and much more: it receives every interaction, decides what the visitor sees next, and loads campaign settings such as payment messages and validation responses. This is configurable software, not a one-off fake page. Who runs it, and whether the same operator is behind every domain in the campaign, remains unproven.

What we proved, and what we didn't

The gap between "the site can do this" and "we saw it done to a victim" is the gap between evidence and speculation.

If you get one of these messages

• Don't pay from a link. Check any FRSC offence through official channels you find yourself, not links from SMS, WhatsApp, social media or email.

• Don't trust the logo. An official-looking page, or a redirect to the real FRSC site, proves nothing about what came before.

• Already entered your card? Call your bank or card issuer now, block the card and ask them to monitor the account.

• Never share an OTP with a website you reached through an unsolicited link.

• Keep the evidence. Save the URL, screenshots, the message and timestamps before deleting anything. They help investigators map the campaign.

From "this is phishing" to "here is how I know"

Modern phishing behaves like software. It keeps sessions open, talks to remote servers, collects data piece by piece, and changes what you see based on what you type.

Spotting a fake site is only the start. The real questions are what the browser is sending, where it goes, what comes back, and which claims the evidence can actually support. Answering them takes web application and WebSocket analysis, traffic inspection, source-code review, IOC extraction, evidence preservation and clear technical reporting.

That is how our cybersecurity programme trains learners: on real investigations, not memorised definitions. We want graduates who can find out what is happening, and who are disciplined enough never to claim more than they can prove.

So the next time a suspicious site appears, don't ask "Does this look real?" Ask: "What is this website actually doing?"

Investigation note

This was a controlled analysis using synthetic test data and captured browser and network evidence. No real banking credentials were used. Indicators are defanged so they cannot be clicked. Claims about real-world losses, completed transactions, OTP interception or the identity of the operator would need separate evidence.