Booking.com показал, как сообщения маркетплейса могут стать поверхностью контроля платежного риска

Кратко

• Публичные страницы безопасности Booking.com и инструкции для партнёров описывают повторяющийся сценарий атак: мошенники атакуют партнёров по размещению фишингом, вредоносным ПО и поддельными сообщениями, пытаются захватить аккаунты Extranet, а затем используют контекст бронирования, чтобы принудить гостей передать платёжные данные или заплатить вне безопасных каналов.
• Сообщения о защите потребителей показывают, что вред был не теоретическим. Австралийские сообщения со ссылкой на ACCC говорили, что упоминания Booking.com в отчётах Scamwatch резко выросли в 2023 году, а британские предупреждения сообщали о 532 заявлениях в Action Fraud и потерях около 370 000 фунтов стерлингов с июня 2023 по сентябрь 2024 года.
• Наиболее весомые открытые данные не позволяют сводить проблему к одному-единственному взлому Booking.com на всей платформе. Источники указывают на схему, в которой сочетаются скомпрометированные аккаунты партнёров, конечные устройства отелей, поддельные платёжные страницы, переход в WhatsApp или по электронной почте и злоупотребление доверительными деталями бронирования.
• Преступники контролировали обман и хищение. Booking.com контролировал архитектуру маркетплейса, базовый уровень безопасности партнёров, предупреждения в сообщениях, сигналы платёжного процесса, каналы сообщений о нарушениях, обнаружение мошенничества и процесс возмещения и поддержки. Партнёры по размещению контролировали локальную гигиену аккаунтов, обучение персонала, безопасность конечных устройств и прямую проверку гостей.
• Вред — это проблема экономики контакта, эксплуатируемого мошенниками. Схема работает, потому что злоумышленник может связаться с гостем в момент максимальной тревоги: после реального бронирования, перед поездкой, с достаточным количеством деталей, чтобы звучать правдоподобно, и с угрозой, что размещение будет отменено, если гость не будет действовать быстро.

Мошенничеству не нужно было взламывать всю платформу

Осторожная отправная точка: публичные доказательства указывают на повторяющуюся схему мошенничества, а не на одно чистое, универсальное событие. Собственнаястраница безопасности для путешественниковBooking.com предупреждает, что злоумышленники могут использовать скомпрометированные данные путешественников для фишинга через WhatsApp, телефон или электронную почту, и советует следить за запросами личных или финансовых данных. Еёинструкция по фишингу для партнёровговорит, что мошенники могут имитировать письма Booking.com, чтобы выманивать логины и пароли для захвата аккаунтов партнёров. Еёинструкция по вредоносному ПОобъясняет, что аккаунты Extranet могут быть привлекательной целью, поскольку содержат ценные данные о гостях и платежах.

Этого уже достаточно, чтобы определить поверхность риска. Злоумышленнику не нужно взламывать основную производственную среду Booking.com, чтобы навредить гостю. Если злоумышленник убедит сотрудника объекта размещения ввести учётные данные на поддельной странице, установит вредоносное ПО на устройство отеля или получит доступ к почте партнёра и затем к Extranet Booking.com, доверенный контекст платформы может стать каналом доставки поддельного платёжного запроса. Гость воспринимает сообщение как связанное с реальным бронированием. Объект размещения может воспринимать его как локальную компрометацию аккаунта.

Booking.com воспринимает его как злоупотребление платформой.

Банк воспринимает его как авторизованный или частично авторизованный ввод карты. Преступник воспринимает его как воронку конверсии.

Это различие важно, потому что в некоторых публичных обсуждениях любое мошенничество с Booking.com сводят к фразе «Booking.com взломали». Эта фраза часто слишком груба. В отчёте Guardian Australia за январь 2024 года о всплеске мошенничеств сообщалось, что Booking.com заявил, что его собственные системы не были взломаны, а некоторые партнёры по размещению стали целями фишинга.

(Guardian Australia о сообщениях о мошенничестве с Booking.com) ABC Australia также сообщила, что количество сообщений о мошенничестве с упоминанием Booking.com выросло, и описала сообщения, связанные с бронированиями, тогда как платформа объясняла проблему фишингом партнёров по размещению, а не взломом собственных систем Booking.com. (ABC Australia о всплеске мошенничества с Booking.com)

Эта граница не должна становиться щитом. Маркетплейс может быть технически прав, что его центральная платформа не была взломана, и при этом нести ответственность за то, как его аккаунты партнёров, потоки сообщений, платёжные сигналы и процессы поддержки формируют вред для потребителей. Гостю не важно, вошёл ли посторонний через ноутбук отеля, повторно использованный пароль, вредоносное вложение или уязвимость платформы. Гость видит реальное бронирование, знакомый бренд, сообщение, которое выглядит как сообщение от объекта размещения, и требование подтвердить данные или оплатить.

Поэтому полезный вопрос не «был ли взломан Booking.com?» как дихотомия. Полезный вопрос: на каждой точке — от кражи учётных данных партнёра до платежа гостя — кто мог снизить вероятность, прервать сообщение, предупредить гостя, проверить канал, ограничить доступ к данным, возместить ущерб пострадавшему или извлечь уроки из повторяющихся сообщений?

Контекст бронирования — топливо для обмана

Эти мошенничества убедительны, потому что они не случайны. Обычное фишинговое письмо с просьбой назвать данные карты — это шум. Сообщение, в котором упоминаются отель, даты, цена, контекст бронирования или риск отмены, застаёт гостя в уязвимый момент. Поездка привязана ко времени. Потеря номера в отеле может испортить отпуск. Гость может находиться в другой стране, пользоваться телефоном, спешить между работой и сборами или сталкиваться с языковым барьером. Злоумышленнику не нужно подавлять всякую критическую мысль.

Ему нужно создать достаточно срочности, чтобы гость перешёл по ссылке, прежде чем проверить платформу, банк или объект размещения по отдельному каналу.

Инструкция Booking.com по защите от мошенничества с арендой на время отпускасоветует путешественникам избегать необычных способов оплаты, не переводить деньги напрямую частному лицу и оплачивать через защищённый платёжный портал платформы, где это возможно. Совет здравый. Проблема подотчётности в том, что этот совет конкурирует с поддельным операционным моментом. Если поддельное сообщение говорит, что бронирование будет отменено через два часа, если не подтвердить оплату, общий совет по безопасности платформы должен присутствовать в той же точке принятия решения, а не прятаться на странице помощи, которую гость читает уже после потери денег.

Потребительская статья Guardian за 2025 год,«Ваше бронирование под угрозой»: остерегайтесь мошенничества с Booking.com, описывала типовую структуру сообщения: заявленная проблема с картой, угроза отмены, короткий срок и ссылка для ввода данных карты. Расследование KrebsOnSecurity за 2024 год,Фишеры Booking.com могут оставить вас с бронированиями, изучило случай, когда учётные данные отеля на Booking.com были похищены, а затем использованы в кампании целевого фишинга против гостей. Эти сообщения — не идентичные инциденты, но они указывают на один и тот же экономический механизм: реальный контекст поездки монетизируется как источник доверия.

Именно так работает экономика контакта, эксплуатируемого мошенниками, на практике. Злоумышленник не просто крадёт данные. Он покупает или крадёт право связаться с человеком в момент высокой конверсии. Бронирование даёт злоумышленнику повод заговорить. Сообщение платформы даёт злоумышленнику заимствованное доверие. Срок оплаты даёт злоумышленнику рычаг. Страх гостя потерять размещение создаёт финальное давление.

Поэтому ценность данных для злоупотреблений контекстуальна. Имя и адрес электронной почты полезны. Имя, адрес электронной почты, дата поездки, отель, статус бронирования, канал сообщений и ожидание оплаты — гораздо полезнее. Если злоумышленник затем может перевести разговор в WhatsApp, электронную почту или на поддельную платёжную страницу, ореол доверия платформы следует за сообщением даже после того, как сделка покидает платформу.

Аккаунт партнёра — часть продукта

Extranet Booking.com — это не внутреннее удобство для отелей. Это часть системы доверия, обращённой к гостям. Если аккаунт партнёра может отправлять сообщения гостям, просматривать детали бронирования, менять условия или взаимодействовать с платёжными процессами, то безопасность аккаунта партнёра — это контроль защиты потребителей.

Собственнаяинструкция Booking.com по предотвращению несанкционированного использования аккаунтаговорит, что аккаунт Extranet содержит ценную информацию, на которую могут охотиться мошенники, включая персональные данные гостей и платёжные данные. Еёстраница сообщения о проблемах безопасностивелит партнёрам сообщать о компрометации аккаунта, запускать антивирусные и анти-вредоносные инструменты и очищать куки. Её более широкийпартнёрский центр конфиденциальности и безопасностисобирает ресурсы по безопасности и инструменты для сообщения о проблемах для партнёров по размещению. Компания явно признаёт, что компрометация партнёра может создать риск для гостей.

Признание — это не то же самое, что сильный базовый уровень. Вопрос политики в том, что платформа требует, а не только рекомендует. Обязательна ли многофакторная аутентификация для каждого аккаунта партнёра? Блокируются ли или задерживаются ли высокорисковые модели сообщений? Оцениваются ли в реальном времени новые устройства, новые страны, подозрительные IP-адреса, необычные массовые сообщения гостям или язык платёжных ссылок? Есть ли у небольших объектов размещения рабочие пути восстановления, которые не упираются в медленные очереди поддержки?

Показывается ли гостям простое предупреждение прямо в той ветке, где сообщение запрашивает данные карты, внешний платёж или новую ссылку?

Могут ли партнёры отправлять платёжные URL-адреса, имитирующие Booking.com, если платёжный процесс не проверен?

Небольшие объекты размещения здесь важны. Многие партнёры Booking.com — это не крупные сети отелей с зрелыми командами безопасности. Это могут быть гостевые дома, апартаменты, семейные отели, операторы краткосрочной аренды, хостелы, сезонное жильё или малый гостиничный бизнес. Сотрудник на ресепшене может обрабатывать сообщения гостей, платежи, звонки по уборке и счета поставщиков с одного и того же устройства. На это устройство могут приходить вредоносные вложения, замаскированные под жалобы на бронирование, документы гостей или корректировки счетов. У отеля может не быть центра операционной безопасности. У платформы он есть.

Страница Booking.com по кибербезопасности для партнёров по размещениювелит партнёрам сообщать о подозрительных атаках на цифровую безопасность и подчёркивает общий характер защиты партнёров. Интервью журналу Click Magazine опередовых практиках кибербезопасности отелейобсуждает компрометацию аккаунтов как растущую проблему для отелей и объектов размещения. Эти ресурсы полезны, но их существование также доказывает, что платформа знает: в её самую слабую группу пользователей входят предприятия с неравномерными возможностями обеспечения безопасности.

Если платформа строит глобальный маркетплейс поверх конечных устройств малого бизнеса, платформа наследует потребность в контролях, безопасных для малого бизнеса. Безопасность не может зависеть от того, что каждый гостевой дом ведёт себя как банк. Продукт должен предполагать, что какие-то партнёрские почтовые ящики будут фишингнуты, какие-то пароли повторно использованы, какие-то устройства заражены, а каких-то сотрудников обманут. Архитектура должна безопасно деградировать, когда это происходит.

Доверие к сообщениям — поверхность контроля

Самая чувствительная часть истории мошенничества с Booking.com — канал сообщений. Сообщение маркетплейса — это не просто текст. Оно несёт неявную аутентификацию. Гости обоснованно полагают, что сообщение внутри бронирования или рядом с ним безопаснее случайного письма. Именно поэтому преступники так стараются захватить аккаунты отелей или имитировать коммуникации платформы.

В британских предупреждениях, обобщённых местными государственными органами, говорилось, что Action Fraud получил 532 сообщения от частных лиц в период с июня 2023 по сентябрь 2024 года, общие потери составили около 370 000 фунтов стерлингов, и что жертвы были обмануты после получения неожиданных сообщений или писем с аккаунта Booking.com отеля, в котором у них было бронирование. Одна публичная копия этого предупреждения доступна черезWired-Gov, и местные советы перепечатывали то же предупреждение. Эти цифры — сообщения о случаях, а не весь ущерб, и они охватывают только британский канал сообщений. Они всё равно показывают, что сообщения, связанные с платформой, создали измеримые потребительские потери.

Дизайн канала должен отвечать на несколько вопросов. Может ли партнёр отправить кликабельную платёжную ссылку в той же ветке, что и бронирование? Если да, то проверяется ли ссылка, ограничивается ли по доменам, задерживается ли или помечается ли? Обнаруживает ли Booking.com типичные фразы вроде «подтвердите карту», «избегите отмены», «оплатите в течение двух часов» или «свяжитесь с нами в WhatsApp»? Показывает ли система предупреждение, когда аккаунт партнёра внезапно начинает отправлять внешние ссылки или требования оплаты сразу нескольким гостям? Могут ли гости сообщить о сообщении одним нажатием?

Замораживает ли сообщение подозрительную ссылку, пока платформа её проверяет?

Получает ли гость ответ человека до истечения срока, указанного в угрозе?

Правильный контроль — это не просто «никогда не отправляйте ссылки». Размещение операционно хаотично. Некоторые объекты используют депозиты, местные налоги, страховочные депозиты, формы по прибытии, инструкции по позднему заезду, процессы проверки личности или прямую авторизацию карты в зависимости от юрисдикции и модели мерчанта. Платформа должна отличать легитимную операционную коммуникацию от высокорискового платёжного давления. Это сложно, но сложность не является оправданием для того, чтобы оставить гостя одного в доверенной ветке.

Страница Booking.com для путешественников советует сообщать о подозрительных контактах в Booking.com. Общие антифишинговые рекомендацииНационального центра кибербезопасности ВеликобританиииФедеральной торговой комиссии СШАсоветуют потребителям проверять ссылки, избегать ловушек срочности и сообщать о фишинге. Эти публичные советы необходимы. Но предупреждения, специфичные для платформы, могут быть гораздо более действенными, потому что платформа знает бронирование, партнёра, платёжную политику, обычные модели сообщений и то, является ли ссылка частью проверенного платёжного процесса Booking.com.

Другими словами, у Booking.com есть контекст, которого нет у регуляторов и потребителей. Он может определить, обычно ли объект принимает оплату через Booking.com, указано ли в подтверждении бронирования, что предоплата не требуется, заплатил ли гость уже, содержит ли сообщение домен, не принадлежащий Booking.com, и был ли доступ к аккаунту партнёра с нового устройства непосредственно перед отправкой. Этот контекст превращает сообщения из пассивной функции в систему контроля мошенничества.

Дизайн платежей решает, кто колеблется

Момент платежа — это когда доверие превращается в деньги. Мошенничество может начинаться с фишинга партнёра, но успех наступает, когда гость вводит данные карты, авторизует платёж, отправляет банковский перевод или проходит поддельный процесс «проверки». Поэтому дизайн платежей должен рассматриваться как часть безопасности.

Публичные инструкции Booking.com путешественникам говорят, что пользователи должны платить через защищённые каналы платформы, где это применимо, и относиться с подозрением к запросам личных или финансовых данных. Её статья о мошенничестве с арендой на время отпуска предупреждает против банковских переводов и необычных способов оплаты.

Это важные красные линии, но многие проживания на Booking.com законно предполагают разные модели оплаты: оплата сейчас, оплата на объекте, предварительная авторизация карты, оплата, управляемая объектом, без предоплаты, плата за отмену, городской налог, страховочный депозит или оплата через стороннего процессингового оператора. Мошенничество живёт в этой сложности.

Вопрос потребителя прост: «Нужно ли мне платить сейчас?» Ответ платформы должен быть столь же конкретным. Гость должен иметь возможность открыть бронирование и увидеть, требуется ли какой-либо платёж, кому, через какой канал и по какой политике. Если в бронировании указано, что предоплата не требуется, сообщение с просьбой немедленно подтвердить карту должно быть явно несовместимым. Если объекту разрешено взимать депозит вне Booking.com, этот факт должен быть закреплён в подтверждении бронирования, а не импровизирован через ссылку, отправленную задним числом.

Если сообщение пытается перевести оплату в WhatsApp, система должна рассматривать это как событие высокого риска.

Предупреждение Guardian за 2025 год описывало сообщения, вызывающие панику угрозой отмены, если гость не ответит быстро. Эта срочность — не случайный приём социальной инженерии. Это механизм, который подавляет сравнение. Понятная поверхность «статуса платежа» в приложении позволила бы гостю сравнить угрожающее сообщение с авторитетным состоянием. Контроль в один клик «Этот запрос на оплату настоящий?» снизил бы когнитивную нагрузку на путешественников, которые не являются экспертами по безопасности.

Банки и платёжные сети тоже находятся в цепочке. Когда гость вводит данные карты на поддельной странице Booking.com, банк-эмитент может увидеть онлайн-транзакцию или попытку проверки карты. Строгая аутентификация клиента может помочь, но она тоже может быть обойдена социальной инженерией, если гость считает, что его просит отель. Права на оспаривание платежа могут помочь постфактум, но гости всё равно теряют время, испытывают тревогу, а иногда теряют деньги. Платформа может снизить вред раньше, усложнив доставку незаконных платёжных запросов и упростив их проверку.

Экономический стимул деликатен. Маркетплейсы хотят бронирования без трения, гибкие модели оплаты партнёров и быстрое общение гостя с объектом. Каждое дополнительное предупреждение рискует вызвать раздражение. Но отсутствие трения именно в неправильной точке создаёт субсидию для мошенничества. Рост платформы зависит от доверия к каналу бронирования; платформа должна также нести проектные издержки защиты этого доверия, когда преступники им злоупотребляют.

Сообщения потребителей показывают измеримую модель ущерба

Австралийские данные — один из самых ясных открытых показателей. The Guardian Australia со ссылкой на ACCC сообщил, что Scamwatch получил 363 сообщения с упоминанием Booking.com в 2023 году по сравнению с 53 в 2022 году, с потерями более 337 000 австралийских долларов. ABC Australia сообщила о том же контексте от органа по защите прав потребителей и описала путешественников, получавших убедительные сообщения, связанные с реальными бронированиями. Текущаястраница статистики Scamwatchописывает публичную среду сообщений о нарушениях, хотя конкретные цифры по Booking.com пришли через отчётность ACCC, на которую ссылались новостные издания.

Эти цифры следует читать осторожно. Сообщения о мошенничестве с упоминанием Booking.com — это не то же самое, что доказанные потери, вызванные платформой. Сообщение может касаться поддельных объявлений, поддельных сообщений, компрометации партнёра, коммуникации вне платформы, обычной имитации или недопонимания со стороны потребителя. Сообщаемые потери также занижают общий ущерб, потому что многие люди не сообщают о мошенничестве, а некоторые возвращают деньги от банков или объектов. Тем не менее, резкий рост сообщений с упоминанием конкретной платформы — это сигнал, что система защиты потребителей увидела повторяемую модель.

Британские предупреждения добавляют вторую юрисдикцию. Цифры из сообщения Action Fraud, опубликованные через публичные каналы, описывали 532 отдельных сообщения и потери в 370 000 фунтов стерлингов за определённый период. И эта цифра — не глобальный ущерб. Это одна система сообщений, один период и один известный набор сообщений. Её ценность в том, что она связывает мошенничество с аккаунтами отелей на платформе Booking.com и с сообщениями или письмами, которые просили гостей произвести оплату или предоставить данные карты.

Уважаемые отчёты по безопасности добавляют контекст со стороны злоумышленника. KrebsOnSecurity описал рынок похищенных или выуженных фишингом учётных данных отелей и случай, когда учётные данные использовались для атак на гостей. Фирмы по безопасности и СМИ также описывали кампании вредоносного ПО против сотрудников гостиничного сектора, включая поддельные жалобы или приманки с «проверкой», ведущие к инструментам удалённого доступа. Эти источники не следует смешивать в один инцидент, если только доказательства не связывают их.

Их следует рассматривать как сходящиеся доказательства того, что проблема компрометации аккаунтов гостиничного сектора экономически привлекательна и операционно повторяется.

Поэтому публичные доказательства поддерживают вывод высокой уверенности: экосистема маркетплейса Booking.com стала повторяющимся каналом злоупотреблений для платёжных мошенничеств. Они не поддерживают безграничный вывод, что каждое мошенничество произошло из одного взлома, что только Booking.com вызвал все потери или что каждый объект был небезопасен. Ответственность здесь распределена, но не растворена.

Поддержка — часть ущерба

Для жертв мошенничество не заканчивается на поддельной платёжной странице. Оно продолжается в поддержке. Гость может связаться с объектом, Booking.com, банком, местной полицией, потребительским агентством или туристическим страховщиком. Каждый может указать на другого. Объект может сказать, что его аккаунт был скомпрометирован. Платформа может сказать, что платёж произошёл вне официального процесса. Банк может спросить, авторизовал ли гость транзакцию. Гостю всё ещё может понадобиться размещение в эту ночь.

Здесь становится видимой ответственность маркетплейса. Если доверенный контекст платформы помог создать риск, процесс поддержки платформы должен быть достаточно быстрым, чтобы прервать потерю, сохранить бронирование и дать гостю чёткий путь к решению. Обычная форма сообщения о мошенничестве недостаточна, когда мошенничество угрожает немедленной отменой.

Гостю нужно знать, действительно ли первоначальное бронирование, безопасен ли аккаунт объекта, была ли подозрительная ссылка поддельной, были ли раскрыты данные карты, следует ли звонить в банк и поможет ли платформа вернуть деньги или предоставить альтернативное размещение.

Сложность в том, что поддержка должна обслуживать и гостей, и партнёров. Небольшой отель, чей аккаунт был захвачен, также может быть жертвой. Он может столкнуться с разгневанными гостями, репутационным ущербом, возможными спорами о возврате платежей и необходимостью вернуть контроль над аккаунтом. Booking.com должен защитить аккаунт партнёра, не замораживая без необходимости законные бронирования. Он должен предупредить гостей, не разрушая доверие к невиновным объектам.

Он должен собирать доказательства из грязного набора каналов: сообщения в приложении, письма, скриншоты WhatsApp, платёжные квитанции, IP-логи, историю входов в аккаунт и банковские записи.

Эта сложность говорит в пользу более сильных инструментов, а не смирения. Платформа должна уметь сохранять подозрительные сообщения, отключать ссылки, определять затронутые бронирования, уведомлять гостей в приложении, помогать партнёрам ротировать учётные данные и создавать простые записи для банков или потребительских агентств. Если команды по борьбе с мошенничеством снова и снова видят один и тот же язык или домены, платформа должна превращать этот опыт в детектирование. Если жертвы постоянно жалуются, что поддержка была медленной или замкнутой, это не просто проблема обслуживания клиентов; это часть ожидаемой прибыли от мошенничества.

Агентства по защите потребителей могут публиковать предупреждения, но они не видят внутреннюю телеметрию мошенничества Booking.com. Банки могут возместить некоторые платежи, но они не могут исправить скомпрометированный аккаунт партнёра. Отели могут извиниться, но они не могут перепроектировать предупреждения платформы. Платформа — единственный участник с полной картиной, охватывающей гостей, объекты, сообщения, домены, отчёты, входы в аккаунты и платёжные политики бронирований.

Обучение партнёров необходимо, но недостаточно

Заманчиво сделать партнёра по размещению главным ответом. Партнёр перешёл по фишинговой ссылке. Партнёр повторил пароль. У партнёра не было чистого конечного устройства. Партнёр не предупредил гостей быстро. Иногда эти факты могут быть правдой. Они всё равно не решают проблему маркетплейса.

Материалы Booking.com для партнёров говорят отелям следить за фишингом и спуфингом, защищать аккаунты, сообщать о проблемах безопасности и запускать антивирусные инструменты. Эти материалы полезны, и их следует продолжать. Они также раскрывают структурный дисбаланс: глобальная платформа может опубликовать инструкции один раз, но тысячи объектов должны выполнять их каждый день в условиях текучки персонала, сезонного давления, языковых различий и неравномерных технических возможностей.

Зрелый базовый уровень платформы должен предполагать сбой партнёра как ожидаемое условие. Такой базовый уровень мог бы включать обязательную МФА для всех пользователей-партнёров; более строгие контроли для пользователей, которые могут получить доступ к платёжным данным гостей; оценку риска устройств и сессий; автоматические блокировки моделей сообщений, запрашивающих внешний платёж; проверенные шаблоны платёжных запросов; состояние платежа на уровне бронирования, видимое гостям; и эскалационные процессы, которые рассматривают компрометацию партнёра как вопрос безопасности гостей.

Он также мог бы включать лимиты частоты и обнаружение аномалий, когда аккаунт, который обычно пишет нескольким гостям, внезапно отправляет много срочных платёжных ссылок.

Ничто из этого не снимает ответственность с партнёра. Объекты должны защищать электронную почту, использовать менеджеры паролей, включать МФА, ограничивать доступ сотрудников, обучать персонал распознавать поддельные жалобы и вложения, отделять личный веб-сёрфинг от управления бронированиями и проверять подозрительные сообщения гостей перед переходом по ссылкам. Управляющие объектами должны относиться к учётным данным Booking.com как к учётным данным платёжной системы, а не как к обычным логинам на веб-сайт. Но платформа не должна полностью зависеть от того, что каждый объект делает это хорошо.

Правильная аналогия — не доска объявлений. Это коммуникационная магистраль, смежная с платежами. Если магистраль может влиять на то, куда движутся деньги, ей нужны ограждения, соразмерные этому риску.

Возмещение должно следовать за контролем, а не за лозунгами

Самый трудный вопрос ответственности — деньги после потери. Кто возмещает гостю, заплатившему через поддельную ссылку, отправленную после компрометации аккаунта отеля? Ответ может зависеть от фактов: произошёл ли платёж на Booking.com, была ли ссылка в приложении или вне платформы, был ли захвачен аккаунт объекта, получал ли Booking.com уже аналогичные сообщения, показывались ли предупреждения, проигнорировал ли гость чёткие инструкции платформы, может ли банк отменить платёж и применимо ли местное законодательство о защите потребителей.

Универсальный ответ был бы несправедлив. Но платформа не должна в каждом случае прятаться за самую удобную границу. Если гость получает мошеннический запрос через канал сообщений, контролируемый платформой, и запрос появляется потому, что аккаунт партнёра имел доступ к деталям бронирования, ответственность платформы выше, чем если бы преступник отправил несвязанное письмо без участия платформы. Если Booking.com позволил сообщению, ссылке или сессии аккаунта оставаться активными после подозрительных сигналов, ответственность растёт.

Если платёж был явно вне всех процессов платформы и гость проигнорировал предупреждения, ответственность платформы может быть ниже, хотя обязанности поддержки остаются.

Логика защиты потребителей практична. Правила возмещения влияют на стимулы к предотвращению. Если потери всегда несут гости, у платформы и партнёров меньше финансовых причин усложнять мошенничество. Если потери всегда несёт платформа, партнёры могут недоинвестировать в гигиену конечных устройств, а преступники могут эксплуатировать поддержку. Справедливая система распределяет издержки в соответствии с контролем: участник, лучше всех способный предотвратить сбой, должен нести самое сильное обязательство по снижению повторяемости.

Помогла бы публичная запись об инцидентах. Booking.com мог бы публиковать агрегированные цифры: сообщения о захвате аккаунтов партнёров, удаления мошеннических сообщений, медианное время ответа, категории возмещения гостям, блокировки подозрительных платёжных ссылок, внедрение МФА среди партнёров и показатели повторной компрометации. Эти метрики не обязаны раскрывать чувствительную логику детектирования. Они показали бы, уменьшается ли проблема, потому что контроли работают, или просто смещается в каналы, которые потребители не видят.

Та же прозрачность помогла бы регуляторам. ACCC, Action Fraud, потребительские организации и органы защиты данных видят жалобы. Им нелегко увидеть знаменатель: сколько бронирований, сколько аккаунтов партнёров, сколько подозрительных сообщений, сколько заблокированных ссылок, сколько подтверждённых мошенничеств и сколько возмещений пострадавшим. Платформа масштаба Booking.com должна иметь возможность публиковать достаточно агрегированных доказательств, чтобы рынок мог оценивать прогресс.

Поддельные объявления и поддельные сообщения нельзя смешивать

Мошенничество с размещением принимает несколько форм, и ответственность становится яснее, когда их разделяют. Одна форма — поддельное объявление: преступник создаёт или копирует страницу объекта, заманивает путешественника и собирает деньги за размещение, которого не существует или которое не принадлежит ему для сдачи. Другая форма — имитация вне платформы: преступник отправляет письмо, сообщение в соцсети или рекламу, которая просто использует имя Booking.com, не касаясь реального бронирования.

Модель в центре этой статьи уже и уже тревожнее для доверия к маркетплейсу: реальное бронирование или реальный аккаунт объекта становятся контекстом для ложного платёжного запроса.

Различие важно, потому что у каждой формы разные контроли. Поддельные объявления требуют проверки объектов, процессов онбординга хостов, обнаружения повторного использования изображений, проверки адресов, целостности отзывов, задержки выплат и быстрого удаления. Имитация вне платформы требует мониторинга защиты бренда, публичных предупреждений, удаления доменов, аутентификации почты и обучения потребителей.

Обмен сообщениями через скомпрометированный аккаунт партнёра требует контролей идентичности, оценки риска сессий, предупреждений, привязанных к конкретному бронированию, сканирования ссылок в сообщениях и поддержки гостей, связанной с записью о бронировании.

Платформа, которая рассматривает все три как общее «мошенничество», будет злоупотреблять широкими советами и недостраивать контроли, соответствующие пути вреда.

Модель скомпрометированных сообщений особенно опасна, потому что она захватывает ранее завоёванное доверие, а не создаёт его с нуля. Гость уже прошёл процесс бронирования. Подтверждение может быть в приложении. Отель существует. Даты и цена могут совпадать. Сообщение может прийти по каналу, которым гость уже пользовался. Это ослабляет обычную грамотность в распознавании мошенничества. Предупреждающий знак не в том, что размещение неизвестно; предупреждающий знак в том, что платёжная инструкция больше не соответствует проверенному состоянию бронирования.

Здесь пересекаются управление справочником и маркетплейсом. Booking.com — это справочник мест для проживания, но также и уровень координации коммуникаций и платежей. Когда путешественник пользуется им, он ожидает, что платформа отличит реальные операции объекта от преступной инъекции. Запись в справочнике можно исправить после обнаружения. Доверенное сообщение, отправленное во время активного бронирования, может переместить деньги за минуты.

Разделение типов мошенничества также помогает избежать несправедливых обвинений. Отель, появившийся в поддельной скопированной записи, может быть жертвой имитации без какой-либо компрометации аккаунта. Сотрудник отеля, поддавшийся фишингу учётных данных, мог совершить локальную ошибку безопасности, но гость всё равно мог быть подвергнут риску, потому что платформа позволила рискованному сообщению нести доверенный контекст бронирования. Гость, заплативший на полностью отдельном поддельном сайте, мог покинуть платформу раньше в цепочке. Средства и предотвращение должны следовать этим фактам.

Для публичной подотчётности Booking.com следует классифицировать сообщения так, чтобы поддерживать это разделение. «Сообщено о мошенничестве» слишком широко. Более полезная таксономия различала бы поддельное объявление, захват аккаунта партнёра, подозрительный платёжный запрос в ветке, имитацию вне платформы, вредоносное ПО против сотрудников партнёра, перехват через WhatsApp, подделку платёжной страницы и спор о поддержке после платежа. Эти метки помогли бы потребительским агентствам понять тенденции и помогли бы партнёрам увидеть, сталкиваются ли они с компрометацией конкретного объекта или злоупотреблением всей экосистемой.

Классификация важна и для предотвращения повторений. Если один аккаунт объекта снова и снова отправляет подозрительные ссылки после входов с новых устройств, вмешательство — это безопасность аккаунта. Если многие объекты получают одно и то же поддельное вложение с жалобой гостя, вмешательство — это защита партнёров от вредоносного ПО. Если гости систематически неправильно понимают законные правила страховочного депозита, вмешательство — это более ясная платёжная политика. Единый котел под названием «мошенничество» скрывает эти различия.

Как могла бы выглядеть более надёжная архитектура доверия

История мошенничества с Booking.com указывает на конкретную архитектуру. Во-первых, идентичность партнёра следует рассматривать как высокорисковый контроль. МФА должна быть обязательной для пользователей-партнёров, которые могут просматривать детали бронирования или связываться с гостями. Доступ с нового устройства должен вызывать дополнительные проверки. Неактивные аккаунты должны истекать. Совместные аккаунты следует ограничивать или технически сдерживать. Привилегированные роли партнёров должны быть узкими.

Во-вторых, риск сообщений должен оцениваться в контексте. Платформа должна обнаруживать внешние платёжные ссылки, фразы о проверке карты, угрозы отмены, переход в WhatsApp, новые домены, необычный язык и всплески сообщений после подозрительных входов. Сообщения высокого риска должны блокироваться, задерживаться или сопровождаться предупреждением, в котором указан платёжный статус бронирования. Гости должны видеть чёткий ответ: оплата через Booking.com, оплата на объекте, депозит разрешён политикой или оплата не требуется.

В-третьих, сообщение о нарушении должно быть немедленным. Гость должен иметь возможность пометить сообщение как подозрительное мошенничество прямо из ветки. Сообщение должно сохранять доказательства, предупреждать объект, отключать рискованные ссылки на время проверки и сообщать гостю, что делать дальше. Партнёр должен иметь возможность сообщить о компрометации и запустить процесс защиты гостей, который выявляет недавние сообщения и предупреждает затронутых путешественников.

В-четвёртых, поддержка должна быть операционно связанной. Поддержка по мошенничеству должна координироваться с поддержкой бронирований, поддержкой партнёров и платёжной поддержкой. Жертва не должна отдельно доказывать, что подозрительное сообщение пришло с реального аккаунта объекта, если платформа может видеть этот факт. Банки должны получать краткие пакеты доказательств при оспаривании мошеннических платежей.

В-пятых, платформа должна публиковать агрегированные показатели подотчётности. Booking.com не нужно раскрывать пороги детектирования или чувствительную архитектуру безопасности. Он всё равно может публиковать внедрение МФА у партнёров, время реагирования на скомпрометированные аккаунты, показатели удаления мошеннических сообщений, подтверждённые результаты поддержки жертв и улучшения предупреждений потребителей. Это превратило бы разрозненные анекдоты о мошенничестве в отслеживаемую программу доверия.

Карта ответственности

Преступники несут первоочередную ответственность за фишинг на партнёров, кражу учётных данных, установку вредоносного ПО, имитацию отелей, создание поддельных платёжных страниц и отъём денег у путешественников. Эта ответственность должна оставаться ясной.

Booking.com контролировал среду маркетплейса, в которой сходились доверенные сообщения, детали бронирования, аккаунты партнёров и платёжные ожидания. Он контролировал предупреждения в продукте, ясность платёжного статуса, требования безопасности к доступу партнёров, обнаружение подозрительных сообщений, потоки сообщений гостей, восстановление партнёров, телеметрию мошенничества и значительную часть опыта поддержки. Он также контролировал то, как публично объяснял проблему и как измерял улучшения.

Партнёры по размещению контролировали локальную гигиену: обучение сотрудников, безопасность электронной почты, защиту конечных устройств, обращение с учётными данными, внедрение МФА, где доступно, дисциплину ролей в аккаунте и прямые предупреждения гостям при компрометации. Некоторые партнёры — малые предприятия с ограниченными возможностями обеспечения безопасности, но это меняет проектные требования к платформе, а не отменяет обязанности партнёра.

Гости контролировали только финальные защитные действия: проверку приложения, отказ от необычных способов оплаты, связь с объектом через проверенный канал, звонок в банк после компрометации и сообщение о мошенничестве. Эти действия важны, но это наименее эффективный слой. Гость узнаёт о риске по одному сообщению за раз. Платформа видит модель на миллионах бронирований.

Регуляторы и агентства по защите потребителей контролировали публичные предупреждения, сбор жалоб и правоприменение там, где применимы законы. Их отчёты показывают вред, но они не управляют маркетплейсом. Банки и платёжные процессоры контролировали мониторинг транзакций и возможности возврата, но обычно видели платёж уже после того, как социальная инженерия добилась успеха.

Вывод об ответственности поэтому общий, но не размытый. Booking.com не обязательно пережил один-единственный центральный взлом в публичных данных. Он действительно управлял глобальной платформой размещения, чей доверенный коммуникационный и платёжный контекст стал ценной преступной инфраструктурой. Для маркетплейса доверие — это не брендовый актив, отдельный от безопасности. Это и есть продукт. Когда мошенники могут снова и снова заимствовать это доверие, чтобы перемещать деньги, дизайн сообщений, безопасность партнёров, ясность платежей и поддержка жертв становятся ключевыми контролями подотчётности.