Phishing and Brand Trust

Definition

The strongest phishing attack does not forge a message. It borrows a channel the target already trusts. When the scam arrives inside a platform’s own internal chat — and the platform emails you about it — the usual heuristics for spotting a fake all pass.

These two pieces record the author being scammed through Booking.com’s host-to-traveller chat in early 2024, nearly losing $8k, and then investigating both the scam site and the platform’s public record.


Core Ideas

Why the trusted channel wins

The reasoning that failed is worth quoting because it is correct reasoning:

People expect a scam on FB Messenger, Telegram, Twitter, even Signal, since they only need your username or phone number, and they are person-to-person, so strange individuals could be potential scammers. However I trusted Booking.com internal chat, because it is a business-to-person chatting system.

The message asked for credit card details to secure a booking — routine on the platform, though normally before payment rather than after. Combined with being in a hurry and a decade of brand trust, an IT professional who knew every relevant security practice left all of them behind.

The lesson is not that the victim was careless. It is that channel legitimacy overrides content scepticism, and platforms that own a trusted channel inherit responsibility for it.

The red flags, visible only afterwards

  • The URL was not under the booking.com domain — the one check that would have caught it.
  • Default timezone, region and currency were Europe/Algeria with a Paris timezone; the user was in Australia.
  • The card form accepted Visa only — no real payment flow does this. Entering a Mastercard still previewed it as Visa.
  • The chat-bot UI was crude and non-functional.

The investigation went further: the card POST went to info.service-id427786413.shop and returned a 503 (which may be why the details never landed). The IP, 91.241.19.123, was a known abuse address registered to a company in Russia; the backend was PHP with a 4.7-second full load.

Platform-side remedies, ranked by cost

#SolutionComplexityNote
1Disable internal chatSimplestScamming continues by email/phone, but the platform is no longer the vector
2Enforce 2FA for host accountsSimpleOnly works if the cause is credential leakage
3URL scanner/alerter on all chat messagesMediumRobust; Outlook, Gmail, LinkedIn and Twitter have done it for years — far better than small-print warnings
4End-to-end encryption in chatMediumZoom’s route, via acquiring Keybase
5Rebuild and rebrand with security practice appliedComplicatedThe reputation play

The disclosure failure

The scams were reported publicly from August 2023 (Reddit, then ABC, Guardian, SMH, ACCC citing a 580% surge). Eight months on the issue persisted, and as a NASDAQ-listed company Booking.com made no public announcement — which the author flags as the surprising part, separate from the technical failure.

Three rumoured causes, none confirmed: hosts being phished at scale; a credentials leak during a payments migration gone wrong; or an insecure chat endpoint allowing use without proper authentication. What the victim’s own experience supports: the scammer could drive the internal chat system convincingly, but could not answer questions — consistent with access to the messaging path rather than to the booking record.

What a user can actually do

  • Check the URL before entering card details — this one check catches most of it.
  • Distrust a website even when you have trusted the brand for ten years.
  • Recognise urgency as the attack: “do this within 2 hours or your booking may be cancelled.” Give yourself a ten-second cooldown.
  • After exposure, freeze the card the same day. The author did, and that is what limited the loss to the leaked email, address, and phone number.

Relationships