В этой статье
12 сентября 2026 года финтех-компания Revolut подтвердила то, что она назвала сложной схемой внешнего мошенничества с выдачей себя за другое лицо: неуполномоченная сторона использовала адрес электронной почты на легитимном домене государственного ведомства, чтобы направить мошеннические запросы информации о клиентах. Запросы были выполнены до того, как схему обнаружили.
Этот инцидент заслуживает вашего внимания именно потому, что в нём нет взлома в привычном смысле. Ни уязвимости в программном обеспечении, ни утёкшего пароля, ни вредоносной программы. Сама Revolut заявила, что её системы и средства клиентов не пострадали. Кто-то запросил данные правильным способом через правильный канал и получил их. Именно поэтому это важно для любой компании, хранящей записи о клиентах, а не только для банков.
Что действительно подтверждено
Мы ограничиваемся тем, что объявила компания и что сообщили профильные издания, потому что расследование продолжается и многое остаётся нераскрытым:
- Метод: письма, отправленные с неавторизованной учётной записи внутри домена, принадлежащего настоящему государственному ведомству, имевшие вес официального запроса информации.
- Данные: идентификационные и контактные данные, включая дату рождения, почтовый адрес, адрес электронной почты и номер телефона, а также копии документов, удостоверяющих личность, таких как паспорта и водительские удостоверения, вместе с изображениями для проверки лица, собранными в ходе процедур «знай своего клиента».
- Масштаб: компания сообщила об ограниченном числе клиентов и не назвала никакой цифры.
- Ведомство: Revolut отказалась назвать государственный орган, чей домен был использован, сославшись на продолжающееся расследование.
- Реакция: адрес был заблокирован, затронутые клиенты уведомлены напрямую, а компания проинформировала соответствующее государственное ведомство, правоохранительные органы, финансовых регуляторов и органы по защите данных.
Исследователь в области криптобезопасности, известный как ZachXBT, оценил, что атака, по всей видимости, была нацелена на состоятельных клиентов, что указывает на составление подробных профилей, а не на неизбирательный сбор. Это оценка исследователя, а не заявление компании, и мы приводим её именно так.
Почему запрос сработал: аутентификация — это не авторизация
Большинство корпоративных почтовых систем опираются на технические проверки, подтверждающие, что сообщение действительно отправлено с того домена, который в нём указан. Эти проверки хорошо работают против обычной подделки: любой, кто выдаёт себя за домен, которым не управляет, получает отказ. Но они созданы, чтобы ответить ровно на один вопрос — ушло ли это сообщение с этого домена?
Вам нужен ответ не на этот вопрос. Ваш вопрос — вправе ли человек, написавший сообщение, запрашивать то, что он запрашивает. Ни одна проверка почты на это не отвечает. Расстояние между этими двумя вопросами — это расстояние между аутентификацией и авторизацией, и именно через этот разрыв прошла вся операция. Когда отправляющая учётная запись находится внутри настоящего домена — будь она скомпрометирована или ошибочно выдана, — все признаки доверия, которые видит ваша команда, будут зелёными.
Практический вывод: задача вашего почтового шлюза заканчивается на доставке запроса в целости. Оценка запроса — работа человека, и для неё нужна письменная процедура, а не личное чутьё.
Ваша компания получает тот же запрос в более простой форме
Легко отложить это в сторону как далёкую историю о европейском финтехе. Но запросы, которые ежедневно приходят в саудовские компании, — это то же самое в более простой одежде: письмо с просьбой прислать выписку по клиенту, сообщение с запросом сведений о сотрудниках для регуляторных целей, звонок с просьбой подтвердить условия договора, письмо с адреса, носящего знакомое официальное название, с просьбой прислать документы для завершения процедуры.
В большинстве малых и средних компаний такой запрос обрабатывается так: он попадает к сотруднику, отправитель выглядит официально, отказ официальному органу кажется более рискованным, чем исполнение, и файл отправляется. Нет записи о том, кто запросил, что ушло и когда. Нет независимого шага проверки. Когда проблема всплывает позже, компании не с чем восстановить ход событий.
Обратите внимание и на оказываемое давление. Срочность вместе с официальным статусом — вот что отключает проверку. Сотрудник, который боится, что его обвинят в препятствовании государственной процедуре, пропустит подтверждающий звонок, и это задуманный эффект такого подхода, а не побочный.
Что требует от вас саудовское законодательство
Закон о защите персональных данных (PDPL) не оставляет этот вопрос открытым. Он возлагает на вашу компанию двойную обязанность: раскрывать данные только там, где это разрешено, и сообщать, если вы ошиблись.
- Статья 15 устанавливает случаи, в которых персональные данные могут быть раскрыты, в том числе когда запрашивающая сторона — государственный орган и запрос служит целям безопасности, исполнению другого закона или выполнению судебных требований, как это определено подзаконными актами.
- Статья 16 регулирует случаи, когда в раскрытии необходимо отказать, в том числе если оно затронет национальную безопасность, поставит под угрозу безопасность людей или помешает текущему расследованию.
- Статья 20 обязывает оператора уведомить компетентный орган и субъектов данных об утечке или незаконном раскрытии. Подзаконные акты устанавливают срок 72 часа для уведомления компетентного органа через Национальную платформу управления данными.
Прочитайте эти три статьи вместе, и проявится решающий момент: закон даёт право государственному органу, а не электронному письму. Запрос, пришедший с домена государственного органа, не становится от этого его запросом. Юридическая обязанность проверки остаётся за вами как оператором данных, и она не переходит к отправителю лишь потому, что он выглядел официально.
Взгляд Origami
Origami — технологическая компания, создающая системы для саудовского бизнеса, и мы постоянно видим одну и ту же картину: почти все инвестиции в безопасность уходят на предотвращение несанкционированного входа — пароли, двухфакторную аутентификацию, межсетевые экраны. Всё это необходимо, но охраняет одну дверь. Инцидент, о котором мы говорим, вообще не проходил через дверь. Он постучал, попросил данные, и ему их вручили. Никакая техническая настройка не помешает уполномоченному сотруднику отправить файл тому, кто запросил его способом, выглядевшим правильно.
Поэтому мы рассматриваем выход данных из компании как процедуру, встроенную в систему, а не как рекомендацию, записанную в руководстве: у кого есть право выгружать данные клиентов, фиксируется ли каждая выгрузка с указанием, кто, когда и зачем её сделал, и проходят ли запросы третьих лиц через путь согласования. Компании, которая за минуту может ответить, какие данные ушли отсюда в прошлом месяце и почему, есть чем защищаться. Компания, которая не может, обнаружит этот пробел в тот день, когда ей понадобится ответ.
Процедура на одну страницу, которую стоит принять на этой неделе
Для этого не нужен ни проект, ни бюджет. Нужно письменное опубликованное правило, которое защищает вашего сотрудника от необходимости решать в одиночку под давлением:
- Никакие данные клиентов или сотрудников не уходят только на основании входящего сообщения. Сообщение открывает запрос, но не исполняет его, каким бы официальным ни выглядел отправитель и каким бы срочным ни был тон.
- Проверяйте через независимый канал. Не отвечайте на сообщение и не звоните по номеру, указанному в нём. Звоните по номеру, опубликованному на официальном сайте органа. Один этот шаг остановил бы всю операцию.
- Один названный по имени согласующий. Один человек, уполномоченный передавать данные внешней стороне, и названный заместитель на время отсутствия. Если разрешение есть у всех, никто ни за что не отвечает.
- Письменный журнал каждого запроса. Кто запросил, в каком качестве, какие данные, кто одобрил, как проверили и дата. Достаточно одной строки в таблице, и её ценность проявится через год, а не сегодня.
- Отправляйте минимум. Если запрос законный, отправьте ровно то, что запросили, а не весь файл или всю таблицу. Объём отправленного — это размер ущерба, если запрос окажется мошенническим.
- Знайте путь уведомления до того, как он понадобится. Кто уведомляет Управление по данным и искусственному интеллекту Саудовской Аравии (SDAIA) в течение 72 часов, через какую платформу, с какими сведениями. Время, потраченное на поиск процедуры, вычитается прямо из срока.
Принцип, лежащий в основе всего этого: проверка — это не препятствование. Настоящий официальный орган не будет возражать против подтверждающего звонка по его собственному опубликованному номеру, а тот, кто возражает против проверки, — как раз тот, кого нужно проверить. Закрепите это письменно для своей команды, чтобы отказ в запросе никогда не был личным риском, который один сотрудник несёт в одиночку.
Источники
- TechCrunch — подтверждение инцидента компанией Revolut 12 сентября 2026 года, её заявление и категории раскрытых данных.
- Bloomberg — сообщение компании о том, что ограниченное число клиентов пострадало в результате мошенничества по электронной почте.
- Управление по данным и искусственному интеллекту Саудовской Аравии (SDAIA) — компетентный орган по Закону о защите персональных данных, его подзаконным актам и Национальной платформе управления данными.
- Закон о защите персональных данных (PDPL) — официальный текст, включая статьи о разрешённом раскрытии, запрещённом раскрытии и уведомлении об утечках.
- Национальное управление кибербезопасности (NCA) — меры контроля, охватывающие защиту данных и управление киберинцидентами в организациях.
Частые вопросы
Если письмо прошло проверки безопасности, в чём заключалось мошенничество?
В том, что домен никогда не подделывался. Письмо действительно ушло с домена государственного ведомства, но с неавторизованной учётной записи внутри него. Проверки подлинности почты доказывают, что письмо отправлено с этого домена; они не доказывают, что написавший его человек вправе запрашивать то, что он запрашивает. В этом разница между аутентификацией и авторизацией, и ни одна техническая настройка не покрывает вторую. Для неё нужен письменный шаг проверки человеком.
Может ли саудовский государственный орган законно запросить данные моих клиентов?
Да. Статья 15 Закона о защите персональных данных (PDPL) устанавливает случаи, когда раскрытие государственному органу допускается, в том числе для целей безопасности, для исполнения другого закона или для выполнения судебных требований, как это определено подзаконными актами. Но это право принадлежит органу, а не письму, на котором стоит его имя. Обязанность убедиться, что запрос действительно исходит от этого органа, остаётся за вами как оператором данных.
Что делать, если я обнаружил, что отправил данные неуполномоченной стороне?
Относитесь к этому как к утечке, а не к административной оплошности. Остановите любую дальнейшую передачу и закройте использованный канал, точно задокументируйте, что было отправлено, кому и когда, затем уведомите компетентный орган в установленный законом срок 72 часа через Национальную платформу управления данными и уведомите затронутых субъектов данных, если их права или интересы под угрозой. Также сообщите органу, от имени которого действовали мошенники, потому что атака редко направлена только на вас.
Какой самый быстрый бесплатный шаг я могу сделать на этой неделе?
Напишите правило из трёх строк и опубликуйте его для своей команды: никакие данные клиентов не уходят только на основании входящего сообщения; проверка означает звонок по номеру, опубликованному на официальном сайте органа, и никогда по номеру, указанному в самом сообщении; окончательное одобрение даёт один названный по имени сотрудник, который записывает каждый запрос в таблицу. Эти три шага ничего не стоят, и их было бы достаточно, чтобы остановить инцидент, описанный в этой статье.
Следите за Origami в Google
Добавьте Origami в предпочтительные источники, и наши статьи будут показываться вам первыми в Google Поиске и главных новостях.








