StayHook: A Hotel-Booking Phishing Cluster

Booking.com phishing pages can borrow more than a travel platform's logo. It can reproduce the sequence of a real booking: the property, the stay, the guest's details, and the final payment step. The domain is different, but the surrounding experience tells the visitor to keep going.

Safety notice. Phishing hostnames are defanged as example[.]com throughout the text and tables. Two kinds of link are deliberately left intact: lookup URLs pointing at registry, DNS and scanning services, which need the literal name to resolve, and one file path preserved exactly as it appears in the recovered artifact. None of them is a link to a phishing page. Do not visit these hosts, and do not submit anything to them.

PhishEye's case PE-1F35BA60 documents that approach at booking.confirm-id12985[.]com. Starting from this report, we examined registration records and public browser captures, then followed the resource fingerprints left by related-looking checkout pages. The investigation produced eight additional registration leads, a set of September checkout hosts sharing identical JavaScript, and a code-reuse connection to a card-collection page served from FEMO IT SOLUTIONS LIMITED's AS214351 network.

PhishEye uses StayHook as a research label for the historical checkout cluster linked by the identical submission script documented below. The Accessstays specimen and reservation-entry template set are related research branches with weaker code and asset relationships, not proof of common control. The current case PE-1F35BA60 prompted this investigation, but its kit fingerprint has not been established: neither that case nor the eight registration candidates is a confirmed StayHook member.

These findings establish infrastructure and software relationships at different confidence levels. They do not establish a single operator, or identify the origin server behind the current reported domain.

Key findings

• 10 September checkout hosts: twelve archived scans loaded the same submission-script fingerprint found in two October 2025 phishing captures.
• 28 reservation-entry domains: a separate historical set shared identical HTML on AS214351. A shared stylesheet connects this template to the Accessstays specimen; that relationship does not establish one operator.
• Eight registration leads: candidates associated with the current case by registration and nameserver patterns. Phishing content was not individually confirmed.

These are distinct observation sets, not counts to add into a single campaign total. Download the dated indicators with their evidence roles and confidence notes.

The case that started the investigation

The preserved PhishEye screenshot shows a Booking.com imitation with guest fields already populated, a property listing, reservation dates, and a price. The page leads toward a final step. We have not independently authenticated the displayed booking details or established where they came from. The screenshot documents impersonation and personalization; it does not, on its own, prove a hotel-account compromise. PhishEye incident report

The case record and registry response establish the following timeline:

Event	UTC time
confirm-id12985[.]com registered	16 September 2026, 12:28:31
Public scan records a FASTPANEL page at the apex domain	16 September 2026, 14:33:26
A later apex scan records an HTTP 403 challenge page	17 September 2026, 07:25:40
PhishEye case created	18 September 2026, 02:22:49

The registrar is Dominet (HK) Limited, IANA ID 3775. The nameservers are razvan.ns.cloudflare.com and wanda.ns.cloudflare.com. The domain was registered approximately 38 hours before the PhishEye case was created. Verisign registration record, public scan history

At collection time, the reported hostname resolved to Cloudflare addresses 104.21.42[.]228 and 172.67.167[.]169. Those are shared edge addresses, not evidence identifying the origin host. The report's stored liveness signal was flagged; we did not revisit the victim-specific page to independently confirm current availability. DNS response, case data

This resembles the guest-facing stage covered in our earlier reservation-hijack analysis. That resemblance provides investigative context, not attribution to a previously named actor.

Eight more registration leads

The closest additional lead is confirm-id12325[.]com. It was registered 8 minutes and 40 seconds after the reported domain, through the same registrar and with the same current nameserver pair. A scan on registration day also recorded a FASTPANEL default page. Registration record, archived page

Expanding the search found nine domains, including the seed, with that registrar and nameserver combination:

Domain	Registered, UTC
confirm-id8564[.]com	14 September, 00:26:18
confirm-id7423[.]com	14 September, 00:29:56
confirm-id8653[.]com	14 September, 12:59:48
confirm-id3568[.]com	14 September, 13:08:15
confirm-id5248[.]com	14 September, 13:20:05
confirm-id4567[.]com	14 September, 13:44:10
confirm-id12985[.]com	16 September, 12:28:31
confirm-id12325[.]com	16 September, 12:37:11
confirm-id86324[.]com	17 September, 20:48:36

Dates are from independently retrieved Verisign RDAP records, preserved in the accompanying evidence package. Examples: 8564, 7423, 8653, 3568, 5248, 4567, 86324.

The timing and naming pattern make these useful hunting leads. They remain candidates, because shared nameservers and a common server-management default page do not prove malicious content or common ownership. FASTPANEL is legitimate software; its default-page hash is not a phishing signature. We keep these eight candidates separate from the archived phishing indicators.

A stronger pivot: identical checkout JavaScript

Older scans of the same numeric naming pattern exposed substantially better evidence. On 28 and 29 October 2025, scans starting at secure-verify-reserve[.]com ended at two Booking.com impersonation pages:

• booking.confirm-id65853049[.]com
• booking.confirm-id43482842[.]com

Both loaded /dist/booking/booking/submit-new8.js. Their query-string version numbers differed, but urlscan recorded the same SHA-256 for the response:

363e2db60a574ebb1946de62e16e61f11caec2d1d15048effe2a1b771e7b2ae5

The captures also recorded chat and status endpoints under /ajax/. The matching script supports shared code, without proving that the pages were run by the same person. 28 October capture, 29 October capture

Searching for that fingerprint in September 2026 returned 12 scans across 10 checkout hosts and six additional entry hosts. We checked the request table of every returned scan to verify that the fingerprint belonged to the checkout script, rather than relying only on the search result.

Checkout host	Observed entry host, where different	September capture
booking.luconfirmriv[.]net	luconfirmriv[.]com	18 September
booking.mrconfirmrfr[.]net	mrconfirmrfr26[.]net; mrconfirmrfr[.]com	18 September, 17 September
booking.flavie-securepay2026[.]net	flavie-securepay[.]net	17 September
myreserv-5534[.]co	—	14 September
hillshoms[.]com	—	11 September
huobsespagna[.]com	—	7 September
booking.frparissuites2026[.]net	parissuites2026[.]net	7 September
booking.gurestprearrivals-status[.]com	—	4 September
booking.prestigeeiffel[.]net	eiffelprestigeconfirm[.]net	3 September
laroomshoms[.]com	—	2 September

The page titles in these September records use individual property names. A detector looking only for the familiar Booking.com page title could miss them, even though the shared script remains observable. The counts describe this bounded archive search, not the total size of a campaign. Reproducible fingerprint search

The FEMO connection: an archived card form and a copied asset path

The network investigation led to a separate, directly observable specimen. A 5 September capture of www.accessstays[.]com records a full Booking.com imitation served from 62.60.226[.]34, which the scan identifies as AS214351, FEMO IT SOLUTIONS LIMITED. The preserved screenshot shows fields for cardholder name, card number, expiry, and CVC. It presents the transaction as securing a reservation, with payment due on arrival and zero due that day. Archived card-collection page

Figure 1. Archived screenshot from the linked urlscan capture, 5 September 2026. The form is evidence of card collection; the image does not demonstrate a completed transaction.

The request records contain a revealing directory structure:

Host: www.accessstays[.]com
Path: /booking/booking.conflrmatlon-id329.com/dist/booking/booking/submit-new8.js

The hostname embedded after /booking/ is part of the local path. It is not the destination of that September request. It is consistent with copied or repackaged website assets retaining a previous hostname.

Three comparisons connect this page to other archived material:

Resource	Observed relationship
index.js	Same scanner-recorded SHA-256 as the October 2025 checkout pages
submit-new8.js	Same filename and nested checkout layout, but a different SHA-256
/main/main.css	Same SHA-256 as a separate FEMO-hosted reservation-entry template

The shared index.js is small, so we do not treat it alone as decisive. Together with the directory layout, related filenames, and visual impersonation, the evidence supports checkout-code reuse or adaptation. It does not establish a common operator. The modified submission-script fingerprint is included in the indicator file.

The embedded hostname also appears earlier in the archive. A 19 February 2026 scan of view.hotelsverifying[.]org, served from 62.60.226[.]85 on AS214351, records an attempted favicon request to booking.conflrmatlon-id329[.]com. No successful response is established for that request. This places the hostname reference in FEMO-hosted material more than six months before the September copied-directory observation. February capture

One reservation-entry page across 28 domains

Another branch of the investigation began with guestverifly[.]org, captured on 6 June 2026 at 62.60.226[.]96. Its page asks the visitor to enter a reservation number and proceed through payment-method verification. urlscan classified the capture as potentially malicious and identified Booking as a targeted brand. Template specimen

The primary HTML has this scanner-recorded SHA-256:

1be1df0088b721aadfc2e2d30676bdfaf11d3ba2176ed931a58ca77fe6a39d37

An exact-hash search returned 37 scans covering 36 hostnames, or 28 domains after removing only a leading www.. Every result in that set records AS214351. The observations span 25 April–29 July 2026, with addresses 62.60.226[.]60 and 62.60.226[.]96. Examples include guestcheclk[.]org, reservationallert[.]org, staychekling[.]org, arrivalchecking[.]org, stayhospital[.]org, and hospitalstay[.]org. The accompanying CSV preserves each observed hostname and its source. Exact-HTML search

The CSS fingerprint connects this entry-page family to the accessstays capture. That supports a template relationship; it does not demonstrate that every entry page led to the same checkout or that every historical domain remains malicious today.

From	Observed relationship	To
October 2025 checkout captures	Identical submission-script hash; core StayHook relationship	10 September checkout hosts
October checkout captures	Identical small index.js and similar checkout layout; weaker relationship	Accessstays card form on AS214351
Accessstays card form	Identical stylesheet; template relationship	28-domain reservation-entry set
February FEMO-hosted page	Requested a hostname later preserved in local asset paths	Accessstays specimen
Current PhishEye case	Registration timing and nameserver pattern only	Eight unconfirmed registration leads

Relationship map. Relationships established by this investigation. The current case remains a separate branch: its origin and kit fingerprint have not been established.

Current checks illustrate why dates matter. On 20 September UTC, Google Public DNS returned NXDOMAIN for both www.accessstays[.]com and guestverifly[.]org. Their preserved captures remain useful evidence, but neither should be described as currently serving those pages. Accessstays DNS check, Guestverifly DNS check

What the provider evidence supports

Our RIPE queries independently confirm the AS214351 registration. The latest returned routing window includes four IPv4 /24 prefixes, rather than the two in the older starting reference. Registry routing-policy statements and observed BGP adjacencies are different measurements; neither should be reduced to a timeless assertion that the network has one peer. RIPE registration, announced prefixes, observed neighbours

The evidence supports the narrower conclusion that specific archived phishing pages were served from addresses observed on AS214351. It does not show that the hosting company operated those pages. Nor does it connect the hidden origin of booking.confirm-id12985[.]com to that network.

Prior DecodeCybercrime reporting on FEMO/Defhost informed that infrastructure lead. Its separate NiceNIC investigation was reviewed as background. We did not establish NiceNIC involvement in the evidence sets documented here. The registration comparisons, resource-fingerprint pivots, and archive correlations above are PhishEye's analysis of the linked primary records.

How defenders can use the findings

Use the reported hostname and dated, archive-supported destinations for incident review. Use the eight new registration candidates for monitoring and enrichment, not automatic attribution. When correlating domains, prioritize multiple matching artifacts over a shared provider or nameserver pair.

The strongest reusable signals in this investigation are the checkout-script fingerprints, the combination of checkout paths and support endpoints, and the exact reservation-entry HTML. A path or CSS file alone is weaker evidence. These signals should complement page content and destination checks, because operators can alter scripts or copy assets between otherwise separate deployments.

Do not block shared Cloudflare addresses or all of AS214351 on the strength of this report. The accompanying indicator file distinguishes historical hosting addresses, observed phishing pages, template matches, and artifact references. It also separates observation dates from the date of this investigation.

For guests, a realistic property page or a correctly populated reservation is not sufficient verification of a payment request. Independently open the booking service or contact the property through a separately obtained channel before supplying card information.

Download indicators and hunting leads

• Dated indicator inventory (CSV): 71 records comprising 61 observed or artifact-referenced hostnames, four historical hosting IP addresses, and six resource hashes. Rows identify the evidence role, observation dates, confidence, source, and recommended use. Inclusion does not mean confirmed StayHook membership.
• Unconfirmed registration leads (CSV): eight candidates, separate from the indicator inventory.

These files reflect evidence collected on 20 September 2026 UTC. Historical IPs, embedded hostname references, and template matches are not an unconditional blocklist. Guest identifiers and victim-specific URL tokens are excluded from these downloads.

For operational next steps, see our phishing website takedown guide and threat intelligence feed guide.

Evidence and methodology

PhishEye correlated its existing incident report with Verisign and registrar RDAP responses, Google Public DNS, RIPE registration/routing data, and existing public urlscan captures. We checked the twelve September scan request tables individually and visually inspected preserved examples of the reservation-entry form, impersonated checkout, and FEMO-hosted card form.

No new public scans were submitted. We did not enumerate reservation identifiers, complete phishing forms, or send payment details. Resource hashes are those recorded in the archived scan metadata; response-body downloads required authentication, so we do not claim to have independently rehashed the JavaScript or reverse-engineered its contents.

The accompanying package contains indicators.csv, a separate hunting-leads.csv, source URLs, saved responses, file-integrity hashes, and the reproducible extraction script. The indicators are new to this investigation's dataset; we do not claim to be the first researchers to observe every listed domain.

Authorship, review, and corrections

This report is prepared under the PhishEye Research byline. AI assistance was used for public-record collection, comparison, and drafting. The checks described above were performed during that assisted workflow; they should not be read as a claim of an independent human technical review. No named human reviewer is credited in this version.

To report an error or supply corroborating evidence, contact PhishEye and identify the StayHook report, the affected claim, and a supporting source. The collection date describes the evidence snapshot; publication and modification dates describe the article. Substantive corrections should be documented here when made.