StopPhish Чат

Revolut: украденные данные клиентов уже используют для шантажа Мы уже писали об утечке в Revolut, где злоумышленники получили конфиденциальные данные клиентов через поддельные запросы от имени госоргана. Теперь появились новые детали атаки и ее последствий. По данным Kela, мошеннические письма отправлялись через скомпрометированный аккаунт государственного ведомства и успешно проходили SPF, DKIM и DMARC. Сотрудники compliance и legal Revolut приняли запросы за официальные и вручную передали запрошенные файлы. По данным источников GovInfoSecurity, злоумышленник получил доступ к системе, которой пользовались итальянские федеральные сотрудники. Предположительно, первоначальная компрометация произошла с помощью RAT. Затем в течение нескольких месяцев атакующий экспериментировал с разными сценариями социальной инженерии. В итоге для запроса данных в Revolut использовали скомпрометированный государственный email-аккаунт и European Investigation Order. Financial Times оценивает число пострадавших примерно в 680 клиентов. Скриншоты, опубликованные человеком под псевдонимом IAmNotAVillain, содержали папку объемом 326 МБ и 688 файлов. При этом, по данным криптоисследователя ZachXBT, среди целей были состоятельные владельцы криптоактивов. О получении уведомлений об утечке публично сообщили, например, бывший CEO Mt. Gox Марк Карпелес и криптопредприниматель Марк Зеллер. Но последствия начались еще до официального уведомления Revolut. Основатель Gamdom Феликс Ромер сообщил, что он и другие пострадавшие получали требования о вымогательстве уже примерно за два месяца до раскрытия инцидента. В качестве подтверждения он опубликовал скриншот попытки шантажа от 26 июля. Для ИБ здесь особенно показателен не масштаб утечки, а вся цепочка. Компрометация одного доверенного государственного аккаунта дала атакующему возможность использовать штатную процедуру раскрытия данных как канал эксфильтрации. Почтовая аутентификация сработала корректно, запрос выглядел официальным, а данные покинули компанию руками сотрудников с легитимными полномочиями. Этот кейс хорошо показывает границу между email security и защитой бизнес-процессов: SPF, DKIM и DMARC подтверждают происхождение письма, но не подтверждают легитимность запроса внутри него. Для операций с чувствительными данными нужен отдельный контроль полномочий и независимая верификация запроса до его исполнения. #StopPhish #SecurityAwareness #ИнформационнаяБезопасность #Кибербезопасность