The SEUR address correction that ends with a card PIN

A SEUR impersonation flow starts with an address correction, introduces a €0.27 delivery fee, and finishes by asking for the card’s four-digit PIN. Between those steps it collects card details and an SMS or banking-app code. All four submissions go to the same PHP endpoint. In the observed runs, entirely synthetic data led to a page claiming successful verification.

The separation matters: someone who stops at the payment demand has already sent their name, email address, telephone number, and postal address. A capture on 12th October 2026 records the first submission and the server's redirect to the card page. The fee appears after collection has begun.

The investigation started with a short-link capture from 10th October. Comparing its preserved pages with earlier records found ten captures covering eight deployment paths on seven hostnames, observed between 22nd September and 10th October 2026. Exact copies of the address form and a visitor-status script connect much of this set more specifically than the shared courier brand or hosting provider does. They establish related software, while the people operating the deployments remain unidentified.

An address correction before the fee

The main link, lnk[.]ink/Seur-Paquete, redirects to vmi3580075.contaboserver[.]net/rdvv/sen/rena/msg.php. The page uses SEUR branding and a tracking display ending in a failed delivery. Its tracking number, 30364601451, is already written into the archived HTML. The display does not require the visitor to supply a parcel number.

The correction page, details.php, asks for first and last names, email, telephone number, street address, city, and postcode. Its form source declares a POST to Assets/php/config/func.php, with a hidden details field identifying the stage.

On 12th October, the browser submitted synthetic personal details to that endpoint. The recorded POST received HTTP 302, followed by a successful request for card.php. This is an observed transfer to the impersonating server, not merely a form action found in source code.

The new page says a service fee of €0.27 is required to complete delivery. It requests the name on the card, card number, expiry, and security code. Its source points to the same PHP endpoint, now with a hidden card field. The card controls themselves have the uninformative names one, two, and three; their labels and input masks establish what they request.

The client code applies familiar formatting masks: groups of four digits for the card number, a month/year pair, and a three-digit security code. It enables “Continuar” when all four controls contain text. Those checks establish presentation and completeness; they do not demonstrate card validation or a payment transaction.

An SMS code, then the card PIN

The same capture continued through the card form. Its card POST, at 17:01:35 UTC, contains the four synthetic payment fields and the card stage marker. The response redirects to loading.php. The transfer is visible; what the PHP handler does with the fields is not.

The waiting page asks the visitor to remain while the shipment is reviewed “securely.” Its JavaScript schedules a navigation to sms.php with setTimeout(..., 5000). A nearby comment says eight seconds, but the executable delay is five. The browser reached the code page at 17:01:41 UTC, after loading the waiting document at 17:01:35.

That transition is a local timer. The waiting-page script does not require a bank response to advance. The preceding PHP endpoint could perform processing invisible to the browser, but the preserved client does not establish any bank validation.

The next form claims that the visitor's bank requires additional verification. It asks for a six-digit code received by SMS or in a banking application. Its action is the same Assets/php/config/func.php endpoint, this time with sms and sms_code fields.

The browser then submitted a synthetic code. The recorded POST received another redirect, this time to loading2.php. That page uses a three-second timer to open pin.php.

The PIN page explicitly asks for the four-digit PIN associated with the visitor's bank card, claiming it needs this to identify the cardholder. Its input is masked, restricted to four digits, and submitted to the same PHP endpoint as the earlier forms. The page presents a bank-verification assurance beneath the button; that text is a claim by the impersonating site.

The fourth POST contains the pin stage marker and pin_code field. Another five-second waiting page leads to a success screen stating that the identity has been verified. Its Continue button points to the genuine www.seur.com site. The capture stopped at the success page; that exit was configured, not observed.

All four reachable deployment paths completed the same four submissions. No genuine bank-issued code or card PIN was used. Reaching the success message with synthetic inputs shows why the page's assurances cannot establish a payment or identity check. It does not reveal the PHP handler's internal processing or prove what happens for other visitors.

A status channel alongside collection

The pages also load Assets/js/stutes.js. This small archived script sends JSON to status/update_status.php. It announces online immediately, repeats that status every 30 seconds, and attempts an offline update when the page unloads.

The JSON includes a field named page, but the code obtains it from window.location.href.split("/")[4]. On the main deployment that produces sen, a directory segment. It does not distinguish msg.php, details.php, and card.php within that directory. The name suggests page tracking, but the implementation supplies a deployment-path label.

The 12th October capture records HTTP 200 responses to status POSTs alongside the navigation. This shows an active reporting channel in the browser. The server-side PHP and any receiving dashboard were not recovered, so the record does not establish what an operator saw or whether the status controlled any later step. The unload handler is a configured attempt; it is not a guarantee that an offline update reaches the server.

What connects the deployments

The strongest link in the earlier records is an identical address-form document. Six captures contain the same SHA-256 hash, including the main case, an 8th October deployment, and two September deployments. Eight captures contain an exact copy of the status script. These are comparisons of application bytes, rather than a match on a common library such as Bootstrap.

Recaptures on 12th October reached an identical card document through six starting URLs. Those URLs resolve to four distinct deployment paths: a short link and a direct URL can be different entries into the same site. The later passes also found identical waiting, code, and PIN pages on all four paths. The common address, payment, status, and verification components support a reused implementation across that reachable subset. They do not establish one operator or a shared downstream recipient.

There are also small differences. Comparing an earlier landing document with the main one reveals a change from a 48-hour deadline to 24 hours. A 1st October variant requests a date of birth as well as contact and address details. These observations do not form a clean upgrade timeline: the address form without the birth-date field was already present in September.

One record exposes a deployment failure. The 3rd October capture starts at msg.php/, with a trailing slash. Relative script and image requests under that path receive the same HTML document instead of their expected resources. A matching landing page therefore does not imply that every recorded deployment completed the collection flow.

The set is best treated as related SEUR impersonation deployments. Generic Contabo server names and a Spanish-language lure are context, not attribution. Exact copies establish software reuse; without a recovered collector configuration or account evidence, both common operation and reuse by separate operators remain possible.

Indicators and method

The table lists deployment paths, not an entire hosting domain to block. The dates are the earliest observations in the reviewed records, in UTC in 2026; they are not creation dates. Redirect and direct captures resolving to the same hostname and base path count once.

Within the reached sites, Assets/php/config/func.php receives the observed personal, card, SMS-code, and PIN submissions. status/update_status.php receives visitor-status reports. Delivery links in the reviewed records use lnk[.]ink, u[.]to, and tr[.]ee; these are shared short-link services, not campaign-owned domains.

Exact SHA-256 pivots used in the comparison:

7a27f2fec4a381f70b9e90ae7af57312c92c7d43f96ffd43c33c645cea3f1016  address form
e4439d4e2e3f97bbb746396c33cadd0f3ee94719e6c971ca53edb7f2f1a1ca8b  status script
62167dc238553679f3047214e3892ceb54ac59fb36cb796de9ef35fcb079449b  card form
370f2c34f3fae2567f884e65bcd5194ffbe35166ba444750673734d11169695b  PIN form

We reviewed persisted public analysis records, complete request listings, rendered snapshots, archived source, and relevant outbound field names on 11th–12th October 2026. Brand, text, similarity, and exact-response-hash searches supplied candidates; source comparisons established the relationships described above. Search coverage is limited to the available records, so these counts are an investigation set rather than an estimate of campaign scale.

All ten original starting URLs were revisited on 12th October. Six reached the payment page; four timed out during initial navigation. A timeout establishes an access limit for that run, not removal of the site. A final pass over the four reachable paths recorded all four submissions and reached success.php on each. Each stopped at its navigation limit, so the configured onward exit remains unobserved. Synthetic inputs were used throughout. No original lure message, victim records, operator account, or completed financial transaction was recovered.

Collection begins before the fee appears and continues beyond the apparent payment step. The address form, card form, SMS prompt, and PIN request are separate transfers to one handler. The final assurance of success closes that visible sequence without establishing a real transaction. Shared application files carry the same collection mechanism across the reachable deployments.