Недавно на хакерском форуме DarkForums появилось громкое заявление о якобы успешном взломе мессенджера Max и похищении 142 ГБ пользовательских данных. Автор поста под псевдонимом CamelliaBtw утверждал, что получил доступ к инфраструктуре сервиса через неизвестную ранее уязвимость нулевого дня и выгрузил около 15,4 млн записей. Спустя короткое время разработчики Max опровергли информацию, а сам «хакер» признал, что никакого взлома не было. История показала, насколько опасными могут быть фейковые сообщения об утечках — и для пользователей, и для репутации сервисов.
Сообщение о взломе мессенджера Max на DarkForums
Согласно публикации на DarkForums, злоумышленник утверждал, что еще на этапе бета-тестирования в начале 2025 года обнаружил 0-day уязвимость в движке обработки медиафайлов мессенджера Max. Под «нулевым днем» в кибербезопасности понимают уязвимость, о которой не знают ни разработчики, ни производители защитных решений, и, соответственно, не существует официального обновления или патча.
По словам CamelliaBtw, эта уязвимость позволила ему встроить вредоносный пейлоад в метаданные стикерпака. Такая схема напоминает известный класс атак, когда вредоносный код прячется в дополнительных данных внутри изображений, документов или других файлов и активируется при их обработке уязвимым приложением. Заявлялось, что это обеспечило злоумышленнику «постоянный доступ» к системе и возможность длительной незаметной выгрузки данных.
Автор сообщения также писал, что пытался связаться с командой Max в рамках bug bounty — программы вознаграждения за найденные уязвимости, — но не получил ответа и потому решил «опубликовать» данные. Он пообещал вскоре выложить первые 5 ГБ якобы украденной информации через торрент-трекеры и в качестве «доказательства» опубликовал фрагменты данных, которые приписал депутату Госдумы Николаю Брыкину.
Позиция разработчиков Max и технические несоответствия
Пресс-служба мессенджера Max в комментарии для СМИ охарактеризовала публикацию на DarkForums как «очередной фейк». Специалисты центра безопасности сервиса представили сразу несколько аргументов, ставящих под сомнение правдивость заявленных «доказательств взлома».
Во-первых, представители Max сообщили, что платформа не использует зарубежные сервисы хранения данных, включая инфраструктуру Amazon. По их словам, все данные мессенджера размещаются на серверах, расположенных на территории России. Это уже противоречит описанию инфраструктуры, приведенному злоумышленником.
Во-вторых, специалисты указали, что Max не применяет алгоритм хеширования паролей bcrypt, тогда как в опубликованных на форуме фрагментах данных упоминался именно этот метод. Для пользователя важно понимать: хеширование — это способ хранения паролей в виде стойких «отпечатков», а не в открытом виде. Наличие в «слитых» данных конкретного формата хеша часто позволяет верифицировать, с каким именно сервисом связана утечка. В данном случае формат не совпал с реальной практикой Max.
Кроме того, команда безопасности заявила, что анализ логов не выявил подозрительной активности, характерной для масштабной компрометации или вывода 142 ГБ данных. Также не зафиксировано ни одного обращения в официальную программу bug bounty от пользователя с ником CamelliaBtw.
Отдельно разработчики подчеркнули, что структура опубликованных записей не соответствует тому, какие данные фактически обрабатывает мессенджер. В «доказательствах» фигурировали поля с локацией, датой рождения, электронной почтой, ИНН, СНИЛС, а также некие «уровни аккаунта» и username. В Max, по заявлению сервиса, не хранятся такие категории персональной информации, не ведется градация пользователей по уровням и не используется username в указанном формате. Это важный индикатор того, что данные могли быть взяты из совершенно другого источника или сгенерированы.
После публикации этих разъяснений CamelliaBtw вскоре признал, что ни уязвимости, ни взлома на самом деле не было, а его пост на DarkForums был сознательно ложным. Он также отметил, что не ожидал столь масштабного распространения новости в Telegram-каналах.
Почему фейковые утечки данных становятся трендом
Случай с мнимым взломом Max вписывается в растущую тенденцию: фейковые «сливы» и псевдо-взломы все чаще используются как инструмент информационного давления, шантажа или простого привлечения внимания. Площадки вроде DarkForums служат удобной сценой для подобных заявлений — аудитория там уже настроена верить в громкие истории о компрометациях.
Мотивация инициаторов таких вбросов может быть разной: от попытки манипулировать репутацией компании до желания монетизировать внимание (например, продав якобы «эксклюзивный» доступ к несуществующей базе). Иногда злоумышленники сначала публикуют фейковые данные, а затем пытаются связаться с жертвой с требованием выкупа, рассчитывая, что та не сможет быстро проверить подлинность утечки и пойдет на уступки.
Риски для пользователей при информационных вбросах
Даже когда «взлом» оказывается вымышленным, риски для пользователей остаются. На фоне шума вокруг бренда мошенники могут запускать фишинговые рассылки, маскируясь под «службу поддержки» и предлагая «срочно сменить пароль после утечки». Переход по таким ссылкам приводит уже к реальной компрометации аккаунтов.
Подобные истории также подрывают доверие к цифровым сервисам в целом и затрудняют работу специалистов по кибербезопасности: на фоне множества фейковых сообщений пользователям все сложнее отличать реальные инциденты от информационных манипуляций.
Как проверять сообщения о взломах и утечках данных
И пользователям, и компаниям важно выработать базовый алгоритм проверки информации о киберинцидентах, особенно когда речь идет о мессенджерах и сервисах, которые ежедневно обрабатывают большие объемы персональных данных.
1. Проверка официальных каналов. Первым шагом должно быть обращение к официальным ресурсам сервиса: сайт, проверенные аккаунты в соцсетях, технический блог, раздел статуса сервиса. Крупные компании обычно оперативно публикуют уведомления о подтвержденных инцидентах и мерах реагирования.
2. Анализ деталей «утечки». Формат и содержание якобы слитых данных часто выдают фейк. Несоответствие полей тому, что сервис действительно собирает, странные или некорректные структуры баз данных, использование технологий, которые платформа не применяет (как в случае с bcrypt у Max), — все это поводы усомниться в правдивости заявления.
3. Сопоставление с практикой отрасли. Реальные крупные утечки, как правило, сопровождаются появлением технических индикаторов компрометации (IOC), исследовательских отчетов профильных компаний, анализов CERT-структур и т. д. Отсутствие какой-либо внешней технической экспертизы при громкой заявленной «масштабной утечке» — тревожный сигнал.
4. Осторожность с «советами» из непроверенных источников. Не стоит переходить по ссылкам и устанавливать ПО, полученное из чатов и каналов, которые ссылаются на якобы «инсайдерскую информацию о взломе». Если есть сомнения — лучше самостоятельно зайти в приложение или на сайт сервиса и сменить пароль через официальный интерфейс, включить двухфакторную аутентификацию и убедиться в актуальности версии приложения.
История с мнимым взломом мессенджера Max показывает, насколько важно критически относиться к новостям о «громких» кибератаках, особенно если они исходят с анонимных форумов и сопровождаются ограниченным набором технических деталей. Для пользователей ключевой стратегией остается цифровая гигиена: уникальные и сложные пароли, двухфакторная аутентификация, регулярные обновления приложений и внимательное отношение к любым письмам и сообщениям о безопасности. Для компаний — прозрачная и быстрая коммуникация в случае инцидентов и выстроенные процессы мониторинга и реагирования. Чем лучше выстроена эта экосистема, тем сложнее злоумышленникам — как настоящим, так и «виртуальным» — использовать страх перед утечками в своих интересах.
