Історія з нібито «зламом» месенджера Max та викраденням 142 ГБ користувацьких даних, що нещодавно активно обговорювалася на хакерському форумі DarkForums та в Telegram-каналах, виявилася повністю сфальсифікованою. Попри це, інцидент показово демонструє, наскільки небезпечними можуть бути фейкові витоки даних — як для користувачів, так і для репутації цифрових сервісів.
Як з’явилося повідомлення про «злам» месенджера Max
На DarkForums користувач під псевдонімом CamelliaBtw опублікував заяву про начебто успішну компрометацію інфраструктури Max. За його словами, ще на етапі бета-тестування в 2025 році він знайшов 0-day уразливість у механізмі обробки медіафайлів месенджера.
Уразливість нульового дня (0-day) — це помилка в програмному забезпеченні, про яку не знають розробники і для якої ще не існує виправлення. Саме тому такі вразливості високо цінуються на чорному ринку і часто стають основою реальних цільових атак.
CamelliaBtw стверджував, що вбудував шкідливий пейлоад у метадані стікерпака, завдяки чому отримав «постійний доступ» до системи Max і зміг непомітно вивантажити близько 15,4 млн записів. У якості «доказу» він пообіцяв оприлюднити перші 5 ГБ через торрент та опублікував фрагменти даних, приписані відомій публічній особі.
Окремо він заявив, що нібито намагався повідомити про знайдену вразливість через bug bounty — програму винагороди за помилки безпеки, — але не отримав відповіді й тому вирішив «злити» базу.
Позиція розробників Max: технічний розбір суперечностей
Команда месенджера Max оперативно спростувала заяви про злам, назвавши публікацію на DarkForums черговим фейком. Фахівці центру безпеки навели низку технічних аргументів, які вказують на підробку «доказів».
По-перше, Max офіційно заявив, що не використовує закордонні хмарні сервіси, включно з інфраструктурою Amazon Web Services. Всі дані нібито розміщені на серверах у Росії. Опис інфраструктури, наведений CamelliaBtw, не збігався з реальною архітектурою сервісу.
По-друге, у «витоку» згадувався алгоритм хешування паролів bcrypt, тоді як Max, за словами розробників, цей алгоритм не застосовує. Хешування — це спосіб зберігати паролі у вигляді криптографічних «відбитків», а не в чистому вигляді. Формат хешів часто дозволяє визначити, який саме сервіс став джерелом витоку. У цьому випадку формат не корелював із практиками Max, що є вагомим індикатором підробки.
По-третє, аналіз логів не показав активності, характерної для масового вивантаження 142 ГБ даних або тривалого несанкціонованого доступу. Також у офіційній програмі bug bounty не знайшли жодного звернення від користувача з ніком CamelliaBtw.
Крім того, оприлюднені записи містили поля з локацією, датою народження, e-mail, ІПН, СНИЛС, «рівнями акаунта» та username у форматі, який не використовується у Max. За заявою сервісу, такі категорії персональних даних взагалі не збираються. Це вказує на те, що база або згенерована штучно, або належить іншому ресурсу.
Після публікації офіційних спростувань саме CamelliaBtw визнав, що ні уразливості, ні зламу не було, а його пост на DarkForums був свідомо вигаданим.
Чому фейкові витоки даних стають новим інструментом атак
Випадок з месенджером Max добре вписується у тенденцію останніх років: фейкові злами та псевдо-утечки даних дедалі частіше використовуються як інструмент інформаційного тиску, шантажу або просто для привернення уваги.
Подібні форуми, як-от DarkForums, створюють аудиторію, готову вірити у гучні історії про злами. Це дає зловмисникам можливість підвищити власну «репутацію», продавати нібито «ексклюзивні бази» або тиснути на компанії, вимагаючи викуп за фіктивні дані. У практиці кібербезпеки вже фіксувалися випадки, коли шантаж базувався саме на суміші реальних та підроблених записів, що ускладнювало перевірку інциденту.
Ризики для користувачів на фоні інформаційних вкидів
Навіть якщо «злам» виявляється вигаданим, користувачі залишаються в зоні ризику. Під шум навколо бренду шахраї запускають фішингові кампанії, маскуючись під «службу підтримки» сервісу та пропонуючи «терміново змінити пароль після витоку». Перехід за такими посиланнями або завантаження «захисних» програм призводить до реальної компрометації акаунтів.
Крім того, множинні інформаційні вкиди розмивають межу між правдивими та фейковими новинами. Користувачам стає складніше розпізнати реальний інцидент безпеки, а компанії — ефективно комунікувати з аудиторією під час справжніх криз.
Як перевіряти новини про злами та витоки даних
Щоб зменшити вплив фейкових витоків даних, важливо мати простий, але чіткий алгоритм перевірки інформації про кіберінциденти.
1. Звертайтеся до офіційних каналів. Насамперед варто перевірити сайт сервісу, верифіковані акаунти в соцмережах, технічний блог або сторінку статусу. Серйозні компанії зазвичай оперативно публікують підтвердження інцидентів та інструкції для користувачів.
2. Аналізуйте структуру «злитих» даних. Звертайте увагу, чи відповідають поля тим даним, які сервіс реально запитує у вас під час реєстрації, чи не використано технології, які платформа офіційно не застосовує (як у випадку з bcrypt у Max). Будь-які невідповідності — привід поставити під сумнів автентичність витоку.
3. Перевіряйте наявність зовнішнього технічного аналізу. Реальні масштабні витоки зазвичай привертають увагу профільних компаній та CERT-організацій, які публікують технічні звіти й індикатори компрометації (IOC). Повна відсутність незалежного аналізу при «гучному» витоку — тривожний сигнал.
4. Ігноруйте підозрілі «поради з безпеки» з неперевірених джерел. Не переходьте за посиланнями з чатів та каналів, що посилаються на «інсайдерську інформацію про злам». Якщо виникли сумніви, самостійно зайдіть у застосунок або на сайт сервісу, змініть пароль через офіційний інтерфейс, увімкніть двофакторну автентифікацію та переконайтеся, що застосунок оновлено до останньої версії.
Історія з фейковим «зламом» месенджера Max наочно показує: інформаційні атаки можуть бути не менш небезпечними, ніж технічні. Регулярна цифрова гігієна (унікальні та складні паролі, 2FA, оновлення ПЗ) у поєднанні з критичним ставленням до новин про витоки даних значно знижує ризики для користувачів. Для компаній ключовими залишаються прозора та швидка комунікація, а також відпрацьовані процеси моніторингу інцидентів. Чим краще вибудована ця екосистема, тим менше шансів у зловмисників — як тих, що реально атакують інфраструктуру, так і тих, хто намагається заробити на страху перед уявними витоками.
