«Мне тут такое фото отправили… не ты на снимках?»
Сообщение пришло поздно вечером, в обычной переписке, от знакомого, который пишет редко. К тексту приложена короткая ссылка — clk1.me/rD7P5E. Несколько секунд я смотрел на экран, прокручивая в голове два варианта.
Первый — что ему действительно скинули какое-то фото, на котором ему почудился я, и он, не разбираясь, переслал. Так бывает, особенно если человек сам не из тех, кто фильтрует входящие.
Второй — что у него увели аккаунт, и теперь от его имени какой-то фишер бомбит ту же приманку всем его контактам, включая меня. Так бывает гораздо чаще.
В пользу второго говорило сразу несколько мелочей. Сообщение было не его обычным стилем — он многоточия не ставит. Время странное — три ночи. И главное: он за два года ни разу не присылал мне ссылок без подписи, какой-нибудь «глянь как круто», «оцени». А тут — голая короткая URL, и вопрос, который, если вдуматься, специально провоцирует ткнуть. «Не ты ли на снимках» — это же мгновенный hook, ты не сможешь этого не открыть, только чтобы развеять сомнение.
Я набрал его в другом мессенджере, спросил, отправлял ли что-то такое. Он был офлайн. Так я остался один на один со ссылкой и вечером, который внезапно освободился.
Открывать на основном устройстве — нет, разумеется. Но что внутри — стало любопытно. Так начинается история, в которой одна короткая ссылка раскручивается в инфраструктуру из 179 фишинговых доменов; оператор за пять дней мигрирует через четырёх хостеров; фишинг-кит оказывается не банальным сборщиком паролей, а MITM-прокси к настоящему API мессенджера MAX; и сам MAX, получив подробный отчёт об уязвимости, молчит уже неделю.
Поехали.
Что внутри коробки
В первой комнате тёмного дома по сценарию должен лежать знакомый интерфейс. Я взял ссылку и положил её в app.any.run — это интерактивная песочница, бесплатная, без регистрации. Они открывают URL в виртуалке у себя и отдают мне видеозапись того, что показывалось, плюс полный лог HTTP-запросов, DNS-резолвов, скриншоты на каждом шаге. Удобная вещь, особенно когда не хочешь пускать что-то через себя. Бесплатные отчёты у них публичные — постоянная ссылка, доступная любому.
Цепочка простая:
clk1.me/rD7P5E → HTTP 302 → maxwel.lol
Сразу скажу про clk1.me, чтобы не оставлять подвешенным: это легитимный сервис коротких ссылок. Свои terms of use, политика приватности, поддержка двадцати языков, отдельный канал жалоб complaint@clk1.me. Никакого отношения к фишеру у самого сервиса нет, как нет вины у bit.ly за то, что им тоже пользуются мошенники. Просто фишер — один из их пользователей. Им я потом написал отдельным письмом, ссылку они должны были удалить по своим правилам.
А вот maxwel.lol — это уже их домен. Открывается копия экрана входа в MAX: «Пользователь поделился с вами фото / Войдите в аккаунт, чтобы посмотреть изображение / Продолжить». Кнопка ведёт на форму ввода телефона. На первый взгляд — стандартный credential harvester.
На первый взгляд.
Кто такой maxwel.lol
Любая работа с фишинговым доменом начинается с трёх вопросов: кто его зарегистрировал, где он хостится, кто DNS. Я открыл who.is, потом ipinfo.io, потом VirusTotal — и записал в блокнот:
Domain maxwel.lol Created 25.04.2026 Registrar Global Domain Group LLC (.lol — Identity Digital) A 212.109.195.59 NS ns1.this-is-face.dev ns2.this-is-face.dev SOA contact support.cloudns.net TLS Let's Encrypt VirusTotal 0/91 — никто не флагнул
Восемь строк, и из каждой что-то понятно.
Домену двое суток. Антивирусные краулеры физически не успели его увидеть — отсюда чистый VirusTotal. Это типично для бизнес-фишеров: свежие домены под каждый прогон трафика именно потому, что они какое-то время невидимы для блокировок.
NS-сервера — собственные, в зоне .dev, под именем this-is-face.dev. Не Cloudflare, не дефолтные регистратора. Кто-то завёл свою DNS-инфраструктуру.
SOA — support.cloudns.net, болгарский DNS-провайдер ClouDNS. То есть зоны обслуживаются у них. Запомним.
IP 212.109.195.59 — Москва, ЦОД в Химках, AS29182, JSC IOT. Российский хостинг.
И вот тут стало интересно.
Сто семьдесят девять
На странице IP в VirusTotal есть вкладка Relations, а в ней — Passive DNS Replication. Это список всех доменов, которые когда-либо разрешались в этот IP. Грубо говоря, кто за последний год прятался за этим IP.
Их там было сто семьдесят девять.
Имена я смотрел минут двадцать, и постепенно картина становилась всё гаже:
max-photo.shop max-photo.one max-photo.online maxpic.lol max-phitog.lol maxonm.lol photomaxcheck.lol maxfod.cc maxphotolifes.cc auth-id8281.cfd openfile.cfd open-file.shop kraskirukids.lol krasivyrisunok.click krasotkagolosovanie.click golosovanie-za-talant.lol konkurs-golos.lol vote-russia.sbs 2gisgolosovanie.today ok-odnokllassniki.ru votemax.online rustore.this-is-face.dev telegram-message.app foxyvideos.lol standoffchit.lol carscanner.lol news7273923.lol news9423782.lol maxinstos.ru ... и ещё 140+
Тематики стандартные для русскоязычного фишинга: «вам прислали фото в чате», «проголосуйте за моего ребёнка в конкурсе», «премиум-подписка», «голосование в 2GIS», «обновление RuStore», «авторизация Одноклассников», «победитель конкурса детских рисунков», «пробив человека по фото из Telegram». Под каждую тему — отдельный домен. Регистрации в дешёвых зонах: .lol, .cfd, .shop, .click, .pics, .top, .one, .sbs, .cc, .life, .digital, .online, .app. Около тридцати разных TLD.
Это не атака конкретно на меня. Это конвейер на сотни тысяч получателей в день, по парсенным и слитым базам номеров. Тебя никто не «заказывал» — твой номер просто оказался в чьей-то старой выгрузке (Сбер, СДЭК, Яндекс.Еда, ВТБ — любая из последних утечек). Друг с большой вероятностью ничего не отправлял — его аккаунт под угоном, и теперь от его имени бот шлёт приманку по списку контактов. Кто-то уже клюнул, кто-то клюнет завтра.
И нашёлся ещё один любопытный экспонат — rustore.this-is-face.dev. То есть оператор работает не только под MAX. Он параллельно держит фишинг под RuStore — российский магазин приложений, в котором сейчас публикуют гражданские сервисы. Через MAX уводят сессию мессенджера; через RuStore, видимо, пытаются устанавливать малварь под видом обновлений приложений. Размах серьёзный.
Картинка целиком
Я зашёл на VirusTotal по самому домену this-is-face.dev. Зарегистрирован он у регистратора Dynadot LLC (зона .dev принадлежит Google Registry), создан примерно месяц назад. Раньше сидел за Cloudflare, в марте 2026 переехал на собственный VPS, в апреле — ещё на один.
И самое важное — у него были сабдомены:
admin.this-is-face.dev ← админ-панель кита api.this-is-face.dev ← API бэкенда rustore.this-is-face.dev ← RuStore-фишинг dev.this-is-face.dev ← дев-стенд ns1.this-is-face.dev ← NS-сервер 1 ns2.this-is-face.dev ← NS-сервер 2 + UUID-сабдомены типа 3a2add4c-5701-490c-8583-299675a06a53.this-is-face.dev
Поверх этого вырисовалась архитектура:
admin.this-is-face.dev ← оператор сидит здесь, в админ-панели api.this-is-face.dev ← бэкенд кита, принимает данные с фейков │ ▼ ns1/ns2.this-is-face.dev ← собственные NS на ClouDNS (Болгария) │ ▼ ~179 фишинговых доменов ← все указывают в один IP │ ▼ 212.109.195.59 ← хостинг с фишинг-страницами
И ключевое: 179 доменов меняют IP одной командой в админ-панели. Оператор обновляет A-записи в зонах через ClouDNS — за минуты весь трафик уходит на новый сервер. Хостер отрубил клиента? За час оператор арендует новый VPS у любого провайдера в любой стране и переводит туда всё. Хостинг — переменная, стираемая. NS-сервера и C2-домен — постоянные. На этом и держится вся конструкция.
Это известная схема, и называется она bulletproof phishing infrastructure. F6 (бывший Group-IB) описывал её на примере панелей Teletron, Social Engineering, Wphisher — ровно те же признаки. Группа арендует или сама пишет «кит» (готовое веб-приложение для штамповки фейков), регистрирует пакет доменов, заводит свои NS, привязывает к одному IP, и через панель управляет всей фабрикой.
В этот момент я понял две вещи. Первая — это организованная коммерческая группа, не школьник. Вторая — у меня есть выходные.
Первая жалоба
Я отправил письмо хостеру abuse@webdc.ru, описав, что у него на одном IP размещены 179 фишинговых доменов одной кампании. Параллельно отписался регистратору Dynadot (через их форму), DNS-провайдеру ClouDNS, регистратору .lol (Identity Digital), и в F6 / Group-IB CERT (cert@cert-gib.ru) — у них есть прямые каналы к российским правоохранителям и к Google Safe Browsing.
К утру следующего дня 212.109.195.59 отвечал ERR_CONNECTION_TIMED_OUT. Все 179 доменов кампании, включая maxwel.lol, лежали с тайм-аутом. Хостер вырубил клиента. Я наивно обрадовался.
Через шесть часов открыл ещё раз. Все домены снова работали. DNS теперь указывал на 79.143.176.86 — Contabo GmbH, Германия. Оператор, как ни в чём не бывало, перевёл всех 179 на новый VPS. Потратил, наверное, минут двадцать.
Это и было то самое доказательство, что хостинг-абьюзы не работают. Снимаешь одну дверь — оператор открывает следующую. Реально его остановит только отзыв this-is-face.dev у Dynadot или отключение зон у ClouDNS.
Я снова отписался — теперь уже в abuse@contabo.de. Но было ясно, что цикл может повториться сколько угодно раз, и ускорить процесс через хостеров — невозможно. Тогда я сел смотреть, что внутри самого фишинг-кита.
Тут начинается странное
В DevTools (Chrome → F12 → Sources, ничего экзотического) я открыл код страницы maxwel.lol. Один inline-скрипт, ~6.5 КБ, не обфусцирован — обычный JavaScript, читается напрямую.
Ни одного внешнего URL. Никаких упоминаний Telegram, никаких mailto, никаких сторонних API. Чистый код, работающий только с собственным бэкендом:
fetch('?action=' + a, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(payload) });
a — это phone, code, password, ping. Эндпоинты на собственном домене, никаких выносов наружу. Это значит, что в клиентском коде нет ничего, что выдаёт оператора. Контакты, Telegram-бот для уведомлений о новых жертвах, управляющая панель — всё на серверном бэкенде, наружу не торчит. Грамотно. Любой нормальный фишер так и делает.
Уже это говорит, что группа не школьная. Профессиональный кит.
И чтобы убедиться окончательно, что у них на серверной стороне — я отправил curl’ом тестовый POST-запрос на их /api/send-code с заведомо некорректным номером:
POST https://open-file.shop/api/send-code HTTP/1.1 Content-Type: application/json {"phone":"+10000000000"}
(open-file.shop — это уже один из следующих по счёту доменов кампании; у них всех один и тот же кит, можно стучаться в любой)
Сервер ответил вот так:
{ "error": "connect: error.phone.wrong: Не нашли этот номер, проверьте цифры", "ok": false }
Я смотрел на этот ответ секунд десять.
Дело в том, что текст ошибки и формат — это дословно ответ настоящего API мессенджера MAX. Локализованное русское сообщение, код ошибки error.phone.wrong с двойной точкой, структура {error, ok} — это всё их формат. Вообще их. Кит не имитирует ответ. Он, чёрт возьми, проксирует мой запрос в реальный API MAX и возвращает мне то, что вернул бы сам MAX.
Это не сборщик паролей. Это MITM-прокси, работающий в реальном времени.
Как это работает
На минуту потребовалось переварить.
Картина оказалась такая. Жертва открывает фишинг и вводит свой номер. Кит на серверной стороне делает примерно следующее:
1. Жертва на open-file.shop вводит +7-XXX-XX-XX-XXX. Браузер шлёт POST /api/send-code на бэкенд кита. 2. Бэкенд кита тут же открывает соединение к НАСТОЯЩЕМУ API мессенджера MAX и отправляет туда тот же самый запрос send-code от своего серверного клиента. 3. MAX принимает запрос как легитимный (а почему он должен его не принять?), отправляет НАСТОЯЩИЙ SMS-код на телефон жертвы и возвращает бэкенду кита идентификатор сессии (waitToken). 4. Жертва видит у себя в SMS реальный код от MAX. Никаких признаков обмана: отправитель тот же, формат тот же, всё как при обычном входе. Жертва доверчиво вводит код в форму на фишинговой странице. 5. Бэкенд кита передаёт код в MAX через POST /api/sign-in с тем самым waitToken. MAX возвращает токен авторизованной сессии. 6. Атакующий получает токен. Внутри её аккаунта. Может читать всю переписку, рассылать сообщения от её имени, через интеграцию MAX ↔ Госуслуги — заходить в её ЛК на госуслугах.
В свежих версиях кита (а кит дописывают, версии я видел разные) появился /api/sign-in-2fa — для пользователей, у которых включён облачный пароль. Жертва вводит свой пароль на фишинге, кит проксирует его в MAX, получает в ответ авторизованную сессию. Двухфакторка не спасает. Просто потому, что она проксируется тем же способом, что и SMS.
Поведение жертвы выглядит идеально-нормальным с её стороны. Она не видит ни одного признака обмана:
— SMS приходит от штатного номера/отправителя MAX — код в SMS — настоящий, действующий — ответ сайта на ввод кода молниеносный, как в реальном приложении — форма выглядит как настоящая — ничего не дёргается, не перестраивается, не «странно тормозит»
Объяснить жертве, что это была атака — почти невозможно. Если она дошла до конца, она войдёт в свой собственный аккаунт MAX и не заметит, что параллельно в этот аккаунт уже зашёл кто-то другой.
Где здесь дыра
Уязвимость не в коде клиентского приложения MAX. И не в Android/iOS-сборках. Она — в политике публичного auth-API. И конкретно в том, что:
— нет проверки Origin / Referer на /api/send-code. Любой третий сайт может вызвать «отправь SMS на этот номер» от своего origin’а, и бэкенд это спокойно сделает — нет первичного SDK-токена. У Telegram эта проблема закрыта много лет назад через api_id/api_hash в MTProto: API не отвечает без валидного токена приложения. У MAX подобного нет, любой неаутентифицированный сервер может звать send-code — нет привязки выпущенной SMS-сессии к идентичности устройства, инициировавшего ввод (TLS JA3/JA4 fingerprint, device id, web-cookie). Поэтому код, выпущенный по запросу одного клиента, может быть «погашен» другим — нет серверного rate-limit’а по характеру источника. Бэкенд кита делает сотни запросов в день на разные номера с одного IP — паттерн, который любая anomaly-detection ловит за минуту — нет push-подтверждения в активные сессии пользователя при попытке нового входа. У Telegram, WhatsApp, Signal — есть. У MAX — нет
Любой одной из этих контрмер достаточно, чтобы класс атаки прекратил работать. У MAX нет ни одной.
CVSS v3.1 я насчитал 8.8 (Critical): AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N. Сетевая атака, низкая сложность, не требует учётки атакующего, нужен один клик жертвы — и у атакующего полный доступ к её аккаунту.
С учётом того, что MAX с 2026 интегрирован с Госуслугами через ЕСИА — это не просто угон мессенджера. Это потенциальный вход в личный кабинет Госуслуг и оформление кредитов, доверенностей, переоформление имущества от имени жертвы. Угон MAX = угон Госуслуг. Это не моё преувеличение — это прямой вывод из их же документации по интеграциям.
Кошки-мышки
Пока я готовил отчёт об уязвимости для MAX, оператор продолжал работу.
Хронология за пять дней:
Дата |
IP |
Хостер |
Состояние |
|---|---|---|---|
25–27.04 |
212.109.195.59 |
JSC IOT (Москва) |
положили |
28.04 |
79.143.176.86 |
Contabo (Германия) |
положили |
29.04 утром |
5.8.53.90 → 5.8.51.6 |
PIN-DC (СПб) |
положили |
29.04 вечером → сейчас |
85.239.144.215 |
DEDIK Services (Германия) |
работает |
Четыре хостера. Пять дней. Один и тот же оператор. Каждый раз на новый IP уходит «боевой» burner-домен (сейчас это open-file.shop), а остальные 178 он оставляет «лежать» на мёртвых IP. Это его оптимизация: подсветившиеся в антифишинг-фильтрах домены он не перевозит на свежий чистый хостинг — они бы его сразу спалили. Перевозит только один свежий, с которого сейчас идёт трафик. Остальные — пул на регенерацию, когда нынешний burner сгорит.
И ещё один штрих, который меня впечатлил. Кит начал отдавать уникальные пути для каждого посетителя. Когда ты заходишь на https://open-file.shop/, тебя редиректит на https://open-file.shop/ahz87nhpu, при следующем заходе будет https://open-file.shop/yt13n0jeh. То есть сама фишинговая форма доступна по случайной строке, выдаваемой при первом обращении. Это защита от URL-based blacklists: Google Safe Browsing работает по точному URL, а не по домену, и такие пути его обходят. Каждая жертва получает свой собственный путь к одной и той же форме.
Уровень оператора — средне-зрелая коммерческая группа. По описаниям F6 это уровень «тимы» — 5-15 человек, есть кодер, топпер (опытный «угонщик»), трафик-менеджер, обналыч. Доход топпера — от 600 тысяч до 2.5 миллионов рублей в месяц. То есть мы говорим про серьёзный криминальный бизнес.
И они знают, что делают. Когда я отправлял жалобу регистратору — они зачищали admin., api., rustore. сабдомены в NXDOMAIN, чтобы убрать следы. Когда падал хостер — они переезжали за час. Когда антифишинг-фильтры начали ловить URL https://maxwel.lol/ — они начали генерить динамические пути.
Вырубить их хостерскими жалобами нельзя в принципе. Они для того и арендуют свои NS на ClouDNS, чтобы мигрировать через любой хостер мира. Закрыть кампанию можно или через регистратора C2 (Dynadot должен отозвать this-is-face.dev), или через DNS-провайдера (ClouDNS должен отключить им сервис), или через MAX (они должны починить API). Всё остальное — игра в догонялки.
Письмо в MAX
К пятому дню у меня собрался полный пакет: разбор архитектуры атаки, воспроизводимый PoC (одна curl-команда), анализ корневой причины, конкретные рекомендации (Origin-валидация, SDK-токен, привязка сессии к device-fingerprint, push-подтверждение, rate-limit), CVSS 8.8, IOC по 179 доменам и истории миграций.
Я оформил это в стандартный отчёт coordinated vulnerability disclosure (cover page, executive summary, severity, technical details, PoC, impact, recommendations, IOC, disclosure timeline, contact). Стандартная структура CERT/CC, как принято в индустрии. Указал 90-дневное окно до публичного раскрытия — общая практика.
Отправил в support@max.ru, копии на возможные адреса безопасности (security@, abuse@).
Прошла неделя. Ни одного ответа. Ни автоматического, ни от человека. Через неделю активно эксплуатируемая уязвимость с CVSS 8.8, доходящая до угона Госуслуг — не вызвала у них ни одного шевеления.
И, что самое скверное, эта уязвимость касается не только текущей конкретной группы. Любая другая группа, посмотрев на этот текст, может развернуть свой кит за два дня. У них для этого даже не нужен талантливый кодер — просто Node.js-обёртка над несколькими POST’ами в API MAX. Это не сложно. Это, в общем-то, почти тривиально.
Что в итоге
На момент публикации этой статьи:
— главный домен this-is-face.dev у Dynadot жив, заявка в работе — DNS-сервис на ClouDNS работает, реакции нет — open-file.shop на DEDIK Services — открывается, жертв собирает — регистраторы по моим жалобам отозвали примерно 15 второстепенных доменов из 179 (часть ушла в NXDOMAIN) — уязвимость в MAX-API — открыта; официального ответа от VK не получено
Я не уверен, что эта статья заставит VK что-то сделать. Но я уверен, что замалчивание не работает. Именно поэтому она тут.
Что делать тебе, если получишь похожую ссылку
Не открывай на основном устройстве и не вводи никаких данных. Если открыл и ввёл — сразу:
— смени пароль на MAX и включи облачный пароль (двухфакторку), хотя в данной атаке она тоже бы не спасла на этапе ввода, она нужна потом для ограничения активных сессий — завершить все сессии MAX кроме текущей — на Госуслугах включить «Безопасный вход» и ограничить сторонние подключения через ЕСИА — проверь свои контакты на похожие сообщения — если у тебя кто-то в контактах увёл аккаунт, эта же приманка пойдёт по твоим знакомым уже от его имени
И сообщи о ссылке:
— в Google Safe Browsing: https://safebrowsing.google.com/safebrowsing/report_phish/ — в Microsoft SmartScreen: https://www.microsoft.com/en-us/wdsi/support/report-unsafe-site — в PhishTank, Netcraft, AbuseIPDB — у clk1.me — на complaint@clk1.me, они оперативно удаляют конкретные shortlink’и — хостеру по IP (определяется через ipinfo.io) — регистратору домена (через WHOIS на who.is) — в F6 / Group-IB CERT: cert@cert-gib.ru
Параллельно — заявление в МВД через Госуслуги, статья 159.6 УК. Без этого регистраторы биллинговые данные клиента не выдадут, но в массиве заявлений твоё письмо станет ещё одним подтверждением.
IOC для тех, кто мониторит threat intel
C2 / NS:
this-is-face.dev Dynadot, IANA 472 ns1.this-is-face.dev 45.83.248.12 AS203391 ClouDNS (BG) ns2.this-is-face.dev 45.83.249.12 AS203391 ClouDNS (BG) admin.this-is-face.dev NXDOMAIN (оператор скрыл) api.this-is-face.dev NXDOMAIN rustore.this-is-face.dev NXDOMAIN
Хостинг (история и текущий):
212.109.195.59 AS29182 JSC IOT (RU) taken down 79.143.176.86 AS51167 Contabo (DE) taken down 5.8.53.90 AS34665 PIN-DC (RU) taken down 5.8.51.6 AS34665 PIN-DC (RU) moved 85.239.144.215 AS207043 DEDIK Services (DE) ACTIVE
Эндпоинты бэкенда кита:
POST /api/send-code приём номера, проксирование в MAX POST /api/resend-code повторная отправка POST /api/sign-in приём SMS-кода, получение авторизованной сессии MAX POST /api/sign-in-2fa приём облачного пароля header _xh: <hex> anti-replay HMAC, генерируется в JS
Сигнатура фишинг-страницы:
title: "MAX – быстрое и легкое приложение для общения и решения повседневных задач" body: "Пользователь поделился с вами фото / Войдите в аккаунт" либо "Пользователь кто-то поделился с вами фото" flow: телефон → SMS-код → cloud password url: https://<domain>/<random8-10> dynamic per-visitor path
Сигнатуры для server-side детекции на стороне самой MAX (если кто-то из MAX security всё-таки прочитал):
- Запросы /api/send-code без Origin или с Origin не из whitelist'а MAX - Один TLS JA3-fingerprint инициирует /api/send-code на десятки разных номеров за минуту - Геораспределение вводимых номеров не коррелирует с одним IP-источником - User-Agent: типовой Chrome/Firefox без характерных для веб-MAX заголовков
Полный список 179 доменов — в комментариях по запросу выложу gist’ом, в основной текст не положил, чтобы не утопить.
Инструменты
Что использовалось из публичного и бесплатного. Никаких регистраций, никаких реферальных ссылок, никакой коммерческой заинтересованности.
— any.run — интерактивная песочница, бесплатный публичный режим. С него началась цепочка. — VirusTotal — детекты, passive DNS, связи между IP и доменами. Это та самая база с 179 связанными доменами. — who.is, ipinfo.io, whois.com — WHOIS, DNS, IP-метаданные. — dns.google/resolve — DNS-over-HTTPS, удобно вызывать прямо из консоли браузера через fetch(). — Browser DevTools — Network tab, Console, Sources. Всё, что я сделал с кодом кита, делается через document.scripts[i].textContent. — curl — для прямого тестирования эндпоинтов кита, вне браузера и его CORS-ограничений. — abuseipdb.com, safebrowsing.google.com, phishtank.com — куда сообщать.
Никаких сложных reverse-engineering инструментов не понадобилось. Кит не обфусцирован, бэкенд возвращает понятные ошибки, инфраструктура у оператора прозрачная для passive DNS. Я не Шерлок Холмс, и DevTools у меня обычный.
Вместо постскриптума
Знакомый, кстати, потом ответил. Аккаунт у него действительно увели, ссылку рассылали с него ботом по контактам всю ночь. Он в этом не виноват, я ему не предъявил ничего. Просто молча дал ему этот текст почитать.
Написать эту статью я начал в субботу вечером с одной ссылкой и любопытством. Закончил в среду утром с пакетом отправленных жалоб в Dynadot, ClouDNS, четырём хостерам, в Identity Digital, в F6 CERT, и с подробным отчётом в support@max.ru. Ситуация на сейчас — фишинг работает на четвёртом по счёту хостинге, MAX молчит.
Если кто-то из VK security всё же прочитает: контактный канал — личка на Хабре, готов ко всему — телефонный созвон, передача полного списка 179 доменов, выгрузка кода кита, координация с CERT-партнёрами. Полный отчёт с CVSS, PoC и рекомендациями уже у вас в support@max.ru. Coordinated disclosure window — стандартный 90 дней.
Если ты дочитал до сюда — спасибо. Если у тебя есть свои находки по этой группе — кидай в комментарии, добьём вместе.
Отдельное спасибо команде any.run за публичный бесплатный анализ, без которого я не стал бы тыкать ссылку. И F6 за исследование «Подноготная угона», которое дало мне правильный фрейм для понимания того, что я разбираю.
Комментарии (120)
MrSmitix
01.05.2026 05:52Сколько их представители говорят о регулярных проверках безопасности, а по факту тут idor, там csrf. Такое ощущение что топ 10 owasp для них даже не шутка, а какое-то бинго которое они целенаправленно пытаются собрать
Lavshyak
01.05.2026 05:52Судя по описанию атаки от автора, ничего не спасет, это MITM атака, полностью виноват пользователь, не проверивший адресную строку.
Astroscope
01.05.2026 05:52На маленьких экранах телефонов никто (ну, почти) не обратит внимание на ненормальное содержимое адресной строки. Это ни в коем случае не оправдание беспечности пользователя, но в общем-то отягчающее обстоятельство, в котором виновен UI мобильных браузеров, который в свою очередь диктуется крайне ограниченным полезным пространством экрана телефона. То есть я на самом деле никого не обвиняю, просто получается, что попасться на такое с телефона еще легче даже тем, у кого зайчатки понимания рисков присутствуют, ну а чуждым цифровой гигиене пользователям так и очевидная аномалия в адресной строке десктопного браузера не поможет.
tuxi
01.05.2026 05:522. Бэкенд кита тут же открывает соединение к НАСТОЯЩЕМУ API мессенджера MAX и отправляет туда тот же самый запрос send-code от своего серверного клиента.Если предположить, что API Макса отслеживает плотность запросов из одного источника, то там под капотом еще и сеть реверс-прокси у такого бекенда должна быть немалая.
Причем, если это запросы с ДЦ (и скорей всего не РФ локации) - то это уже сам по себе звоночек для такого API "тут что-то неладное творится".Lavshyak
01.05.2026 05:52да полюбому основной бэкенд хацкеров проксирует еще это на близжайший к пользователю прокси-сервер или VDS внутри РФ.
pvlbgtrv
01.05.2026 05:52чел тебе че интернет провели? тысячи школьников этим занимаются, и тг угоняют и макс, и будут угонять, пока авторизация в сервисе работает, хоть миллион статей напиши
несколько дней жизни на школьников потратил мда, еще так пишет будто инфру Zeus 2026 или Lockbit нашел
Persik1
01.05.2026 05:52А вы сами из тех самых "школьников", раз так агрессивно защищаете их честь?
Суть статьи не в том что фишинг существует, а в том как именно он технически реализован под конкретную дыру в Максе
0x22
01.05.2026 05:52под конкретную дыру
Объясните, что за дыра? Без шуток, реально не понимаю.
a3or
01.05.2026 05:52Между клавиатурой и стулом, очевидно же.
Кроме шуток - доступность в угоду безопасности. Фишинг тем и живёт, но обзывать его дырой - хз, сомнительно.
k4ir05
01.05.2026 05:52В статье же раздел про это - "Где здесь дыра"
0x22
01.05.2026 05:52Раздел есть, дыры нет. Я не просил указать где в статье текст о дыре. Что есть дыра, в чём бага до уровня 8.8?
k4ir05
01.05.2026 05:52Согласен, при внимательном прочтении (сперва бегло просмотрел) статья кажется мутноватой. Но если там не всё выдумки, то отсутствие подтверждения (или хотя бы уведомления) в другие сессии о новом входе не очень безопасно. А вообще, с учётом его интеграции с госуслугами, весь этот функционал с ботами и открытостью API сами по себе выглядят дырой.
zeroc0de
01.05.2026 05:52Объясните, что за дыра? Без шуток, реально не понимаю.
Нет проверки Origin / Referer на /api/send-code
Нет привязки выпущенной SMS-сессии к идентичности устройства, инициировавшего ввод
Нет серверного rate-limit’а по характеру источника
Нет push-подтверждения в активные сессии пользователя при попытке нового входа
Автор с пояснениями написал про эти уязвимости и как их закрыть.
Пояснение пункта 1 на практике.
На https://auth.mail.ru/cgi-bin/auth?mac=1 была такая уязвимость, что подключив этот адрес на своем сайте через <script src>, можно было получить данные авторизованного пользователя. Т.е. владелец сайта мог узнать настоящие почтовые ящики того, кто посетил его сайт, и что самое критичное, для сбора данных даже нет нужды заманивать человека на свой сайт, достаточно написать кому то сообщение (на форумах, соц сетях и тд), указав в сообщении <img src> с указанием ссылки на свой сайт, а на самом сайте править htaccess
AddType application/x-httpd-php52 .jpgПольза зависит от фантазии.
Такая же уязвимость была и на yandex, сейчас не помню api адреса яндекса.Mail.ru исправил уязвимость тем, что начал проверять Origin / Referer, и этого хватило, чтобы "закрыть" уязвимость, т.к. js не умеет отправлять Referer. Обходится с некоторыми усилиями через протокол
data:.0x22
01.05.2026 05:52Нет проверки Origin / Referer на /api/send-code
При отправке тем же питонячим requests можно поставить ЛЮБОЙ Origin / Referer
Нет привязки выпущенной SMS-сессии к идентичности устройства, инициировавшего ввод
Для web-версии? Проверка идентичности браузера и всех метрик?
Нет серверного rate-limit’а по характеру источника
Откуда данные? Необходимо иметь логи маха, чтобы знать, с одного ли IP идут запросы или проксируются ещё через множество.
Нет push-подтверждения в активные сессии пользователя при попытке нового входа
Допустим да.
CVSS 8.8 Critical точно.
То, что Вы привели пример мэйла, работало, тоже помню, но в примере автора запросы шли с сервера, а не JS.
zeroc0de
01.05.2026 05:52Объясните, что за дыра? Без шуток, реально не понимаю.
Вы задали вопрос, чтобы начать спорить или получить ответ?)
Способ, который позволяет залезть в голову пользователю в среде, которую контролирует разработчик - это дыра, которую разработчик не закрыл. Один только Google столько всего придумал против фишинга, что многие способы залезть в голову пользователю google, казавшиея вечными, перестали работать.
Проблемы с фишинговыми ссылками решались по разному, например, варианты навскидку:
1. Подгрузка сайта по ссылке в небольшом фрейме в самом сообщении с переходом по всем редиректам вполне себе покажет, как выглядит конечная точка, без необходимости клика по ссылке.
2. Любая ссылка в мессенджере открывается только через промежуточный прокси адрес, вроде checklink.max.ru, который на 2-3 секунды задержит открытие ссылки, но предварительно проверит безопасность ссылки.
3.1 Проверять домен из ссылки на давность регистрации, указывая у новых доменов, что он зарегистрирован недавно.
3.2 Автоматически проверять ссылки на наличие редиректа, будь то редирект Location, или другой редирект, и помечать такие ссылки как сомнительные.
4. При запросе токена на авторизацию, проверять наличие и время активной сессии в момент запроса токена, и если активная сессия присутствует и время соответствует моменту отправки запроса, слать сообщение на номер телефона с уведомлением вроде, что пользователь уже авторизован в устройстве iPhone, и вводить код только в том случае, если пользователь пытается авторизоваться в другом устройстве. Что то в этом роде.
Это дыра? - Да.
Ее можно закрыть? - Да.
Дыра критичная? - Да, если судить по последствиям для жертвы. Нет, если судить по масштабу урона для Макса.
ps. Надеюсь, вы не Великий M_Script. Стиль письма похож.0x22
01.05.2026 05:52Задал вопрос, чтобы получить ответ, но именно в рамках данного поста. То есть того, что описал автор.
У нас совершенно разное представление критичности уязвимости. Если проверка Origin/Referer является критичной, то что за уровень у RCE? Последствия..значит и сам смартфон уязвим, раз на нём такое открыть можно в принципе. Критичность не так определяется в данном случае. Если для юзера, то хоть XSS, хоть Smuggling - данные утекли, можно воспользоваться, только вот при XSS том же - виноват разработчик, а при фишинге - сам себе виновник.
Проверка ссылок:
3.2 Автоматически проверять ссылки на наличие редиректа, будь то редирект Location, или другой редирект, и помечать такие ссылки как сомнительные.
К примеру в URL в конце нет слэша, на некоторых сайтах идёт редирект на URL со слэшем в конце. А сайт вполне себе легитимный, но по правилам становится сомнительным тогда.
Авторизован или нет - тоже может быть редирект на промежуточную страницу.
Версия браузера, вэб или мобильный и т.п. Это навскидку примеры, при которых будет 302 или в META тэге, таким образом все идут в сомнительные. Не годится такая защита.
3.1 Проверять домен из ссылки на давность регистрации, указывая у новых доменов, что он зарегистрирован недавно.
Ну это уж совсем для наших людей :)
Будет такое:
Скрытый текст
Бесполезно, будем щемиться дальше. 2. Любая ссылка в мессенджере открывается только через промежуточный прокси адрес, вроде checklink.max.ru, который на 2-3 секунды задержит открытие ссылки, но предварительно проверит безопасность ссылки.
А как проверит? На наличие небезопасного текста на странице? Всё отрисуется JS-кой, а checklink.max.ru увидит что-то простенькое и безобидное.
1. Подгрузка сайта по ссылке в небольшом фрейме в самом сообщении с переходом по всем редиректам вполне себе покажет, как выглядит конечная точка, без необходимости клика по ссылке.
Получает юзер такое сообщение с несколькими разными ссылками и у него вместо сообщения отрендерится такая страница аля нулевые, всё мигает, всё разное и грузит полдня.
Вообще любые переходы по ссылкам, которые может инициировать сервис типа для проверки, до того, как отдать пользователю - не лучшая затея, так как есть одноразовые ссылки например, сброс пароля, подтверждение и т.д, и т.п.
4-й пункт верный подход.
M_Script, знакомое, но не могу вспомнить точно, это модер какой-то был на античате или вроде того?
zeroc0de
01.05.2026 05:52M_Script, знакомое, но не могу вспомнить точно, это модер какой-то был на античате или вроде того?
Он. Тихий модер раздела "Социальные сети" и... один из лучших исследователей веб-безопасности в RU секторе, создатель уникальных векторов атак и авторских 0-day.
k4ir05
01.05.2026 05:52Получает юзер такое сообщение с несколькими разными ссылками и у него вместо сообщения отрендерится такая страница аля нулевые, всё мигает, всё разное и грузит полдня.
Вообще любые переходы по ссылкам, которые может инициировать сервис типа для проверки, до того, как отдать пользователю - не лучшая затея, так как есть одноразовые ссылки например, сброс пароля, подтверждение и т.д, и т.п.
Так телеграм и вотсапп так и делают - они ведь показывают превью ссылок. Но там не всё содержимое ссылок рендерится, а по протоколу Open Graph.
А сброс пароля через GET запрос, такое вообще бывает? В каком случае это может быть оправдано?
0x22
01.05.2026 05:52В Open Graph превьюшка же может отличаться от содержимого. Сброс пароля по GET сейчас вероятно крайне редко где встретишь, а вот подтверждение с уникальным идентификатором - вполне, что добавит как раз вектор атаки, если сервис сам "кликнет" по ссылке до юзера.
k4ir05
01.05.2026 05:52В Open Graph превьюшка же может отличаться от содержимого
Может, но в данном контексте это не важно. Важно то, что мессенджеры уже открывают ссылки до юзера. Ну а передавать чувствительные ссылки через мессенджер не очень разумно, ИМХО.
Lavshyak
01.05.2026 05:52нет никакой дыры в максе. пользователь сам на домен не смотрит, такую атаку нечем контрить
tklim
01.05.2026 05:52Как лихо автор присвоил 8.8 и "в один" клик.
А ничего что ещё надо не смотреть на домен, ввести телефон, ввести код из СМС и т.д.?
Ну и про телеграмм - тут были недавно посты про клиент "Телега", где тупо пропускали весь траффик через себя.
Freeman_RU
01.05.2026 05:52Телегу надо установить самому. Это уже активное действие, то есть фактически передача добровольная.
Из всех угютов вещают, что мах - супер безопасный, там нет плохишей и вообще можно спокойно пользоваться. С учётом, что смс приходит с легального номера заподозрить неладное для обычных людей очень сложно. Так что да, это очень высокий уровень.
tklim
01.05.2026 05:52Макс тоже надо самому поставить, внезапно.
Я не знаю, с какими утюгами вы общаетесь, но здесь на хабре (и везде где он упоминается) через одну статьи об уязвимостях и проблемах Маха. И может было 1-2 "от авторов" с попытками опровержения.
Grey_Box
01.05.2026 05:52Действительно.
А: Людей заставляют скачать макс.
Б: Любой утюг, да хотя бы тот же телевизор. Если ты не видел, сидишь только тут, то это не значит, что этого нет. Или вам из чайника виднее? Кроме того, подавляющее большинство людей, скачавших макс, не сидят на хабре.tklim
01.05.2026 05:52Лично я при всем желании не смогу законно/официально поставить этот Макс. Хотя было бы интересно поковырять уязвимости.
Если вы апеллируете к телевизору или к тому что "большинство" не замечает этого "анти"-хайпа против Макса, то значит, "они" таки победили.
ValeriyFilatov
01.05.2026 05:52С учётом, что смс приходит с легального номера заподозрить неладное для обычных людей очень сложно.
Я извиняюсь, а разве бывает по другому?
Какой смысл в смс с "нелегального" номера?
d1mk0
01.05.2026 05:52Думаю, автор имел в виду случай, когда логинишься в макс, а смс приходит от сбербанка
qwe101
01.05.2026 05:52Если не блочат, значит это кому-то нужно? Коррупционную составляющую пока не отменили.
house2008
01.05.2026 05:52Видимо уже ни кнут ни пряник не работает для загона в про правительственные каналы, только так хоть как-то накрутить пользователей и голосования.
kunix
01.05.2026 05:52А кто мешает делать такой же фишинг и логиниться, например, в Telegram с backend?
Ну то есть, если оригинальный клиент телеграм может залогиниться, то и мы можем, там в нем нет ничего секретного.Можно как-то с этим бороться, лимитировать запросы на один IP, но это все тлен.
P.S. Не могу комментировать чаще, чем раз в час.
Я статью почитал, ничего не понял. Нужны детали. С теоретической точки зрения никто не мешает у себя под кроватью запустить ферму с Android-мобилами с Telegram и делать все на 100% легитимно. Это конечно же overkill, думаю, все решается в разы проще и эффективнее.
farfromanyroad
01.05.2026 05:52Статью внимательно читайте, там все написано и в телеграме такое давно пофиксили в том числе валидацией запроса со стороны клиента. Даже если клиент сторонний типа телеги, запрос отклоняется если по пути проходит через кого то еще. Тут же можно запрос через 10 серверов перекинуть и сервер макса его примет отдав токен в неизвестном направлении.
tklim
01.05.2026 05:52Если у приложения есть веб-версия, то архитектурно невозможно предотвратить MITM. Можно только косвенно "подозревать": левый айпи, много запросов с одного айпи и т.д. ну и козырное - "вы зашли с нового устройства, браузер хром, айпи хз.хх.хх.хх, местоположение Франкфурт, это точно-точно вы??"
KseandI
01.05.2026 05:52Но запрос ведь не проходит через кого-то ещё, он создаётся этим кем-то, нет? На фишинг летит логин/пароль, с фишинга летит запрос на сервера макса, как это можно предотвратить вообще?
gudvinr
01.05.2026 05:52Certificate pinning - отбрасываются левые CA
Channel binding через tls-exporter из TLS 1.3 - подтверждается идентичность сессии
Ничего из этого не работает в вебе, но концептуально невозможность перехвата MITM обеспечить реально
Для веба есть варианты, которые позволяют не передавать пароль в открытом виде, но не помню есть ли в них защита от replay атак
Akuma
01.05.2026 05:52Как валидация на клиенте может предотвратить авторизацию на стороннем сервере? Туда приходят логин-пароль в открытом виде. Далее имитируются вторые-третьи-десятые факторы и мы получаем валидную сессию.
Persik1
01.05.2026 05:52Если вы попытаетесь массово запрашивать СМС с бэкенда через Telegram API, ваш IP и ваш api_id улетят в бан за подозрительную активность (rate limit) в течение нескольких минут. Фишинговой ферме придется постоянно регать новые api_id с чистых IP, что экономически нерентабельно
В Максе бэкенд принимает запросы откуда угодно
kunix
01.05.2026 05:52Ну ок, т.е. речь уже идет не про то, что это невозможно, а про то, что массово сделать нерентабельно? Я почему-то думаю, что у специалистов это все схвачено. Тупо есть поставщики небитых-некрашеных проксей за приемлемый прайс.
И на кой черт мне каждый раз регать новый телеграм клиент с новым api_id? Я буду запускать настоящий Telegram с ломаного Android-телефона с подменой идентов. Причем на один телефон будет много независимых инстансов Telegram и каждый будет видеть свои иденты.
Тут из подозрительного только одно - что с одного IP слишком много запросов на логин одновременно. Но читаем выше. Ну и блин, настоящих людей, сидящих с VPN никто не отменял. То есть, некоторый уровень логинов с одного IP - это нормально.
Пресловутая Телега как-то же делает MITM и пропускает трафик через себя? И работает же. В чем принципиальная разница?
event1
01.05.2026 05:52А если использовать параметры от официального клиента? Или они у каждого юзера разные?
tklim
01.05.2026 05:52Скажите, какой будет айпи, если использовать сибокс с симками того же оператора из того же региона?
Что-то мне подсказывает, что это будет один и тот же адрес/пул как и для обычных мобильных пользователей.
И в случае телеграмма или прочих сигналов не выйдет договориться с операторами, чтоб они отдавали дополнительные метаданные (как это обычно работает с банками)
Akuma
01.05.2026 05:52Не совсем понятно что с этим должен делать ВК. Прокинуть авторизацию можно хоть в Гугл, никто не мешает. Это просто авторизация.
Если пользователь вводит свои данные на левом домене - ни один сервис не защититься от этого.
vikarti
01.05.2026 05:52В статье ж указано - проверять откуда (IP) приходит запрос, рейтлимиты и гео.
Мне вот вспоминается моя попытка бота под MAX сделать - там при регистрации стоит проверка по гео - без отключения VPN - сразу сообщения что превышен рейтлимит.
Ну да - возможно у авторов кита есть много резидентских ру-прокси.
riky
01.05.2026 05:52если они там миллионы зарабатывают то могут себе позволить простые мобильные прокси за тыщу в мес. на которых ип каждые пару минут меняется и он локальный в рф. думаю так и делают…
zeroc0de
01.05.2026 05:52Кстати, они там миллионы потому и зарабатывают, потому что это легко. Как только становится тяжело зарабатывать миллионы в одной сфере, то они бросают эту сферу и переходят в ту сферу, где все еще легко зарабатывать миллионы. У них нет цели тратить тыщу в месяц, если это не окупается в десятки раз. А меньшая окупаемость в этой сфере невыгодна.
KseandI
01.05.2026 05:52В статье указано, что api_id магическим образом решает все проблемы. Не сказано, правда, как, только сам факт, что тг это решили. И как поможет проверка ip? На что его проверять? Рейтлтмит? Когда скамеры за час могут поднять новый VDS?
Akuma
01.05.2026 05:52А еще в статье не указано как это хоть чем-то поможет. Третий раз укажу, что прокси обойдутся в пару-тройку тысяч в месяц, это копейки, от реальных не отличишь. На крайняк никто не мешает поднять ферму реальных устройств.
ViskasSP1vom
01.05.2026 05:52Действительно, зачем вообще делать безопасность в приложении
Давайте просто скажем: "Пользователь сам виноват, что ввел код, наши руки чисты"
Идеальная стратегия для мессенджера, интегрированного с Госуслугами
Akuma
01.05.2026 05:52Пользователь сам заходит на фишинговый сайт, он видит домен, он вводит свои данные. Никто и ничего с этим поделать не сможет в принципе. Это проблема в прокладке между стулом и монитором. Только обучить ее.
yahooyaks
01.05.2026 05:52Вот вы удивитесь, если окажется, что эти мошенники - кого надо мошенники. Прокладок прогнули на очередной скам, а самые стойкие теперь - антимаксеры.
AVikont
01.05.2026 05:52app.any.run— это интерактивная песочница, бесплатная, без регистрацииКак воспользоваться без регистрации?
Dzzzen
01.05.2026 05:52Я вообще не понял, зачем понадобился any.run. Редирект 30х можно в dev-tools браузера посмотреть. Или если надо красиво, то здесь: https://www.redirect-checker.org/
0x22
01.05.2026 05:52Автор, судя по накрученному вами аж до 8.8 (Critical), вы явно вдохновились выплатой до 10M ₽ - это из https://bugbounty.standoff365.com/programs/max
Но как заметили выше, необходимо ввести номер, код и т.п действия.нет проверки
Origin/Refererпри запросе на апи, скрипт на сервере добавит какой угодно
RefererилиOriginОтсутствие Rate limit, проверки IP на множество соединений, идентификатор устройства - да, недочёты явно, но это не 8.8, видимо здесь ИИ решил не огорчать вас и порадовать на всю катушку, возможно добавив сформированный отчёт(лишь предположение, может ИИ не использовался совсем).
Впрочем триажеры могут рассказать много интересного об отчётах с CVSS 8+, сгенерированными особенно много за последнее время. Может есть кто из триажеров, опубликуют подобный пост без раскрытия?
Yurchicnice
01.05.2026 05:52ИИ тут явно использовался, судя по конструкция "это не, это а", томным кратким предложениям и еще кучи признаков, что мне лень описывать
akakoychenko
01.05.2026 05:52Несколько раз перечитал советы от автора о том, что не сделали разрабы, и, правда, не понял сути
нет проверки
Origin/Refererна/api/send-codeПрокси подставит туда именно то, что надо. Не понимаю, как должно помочь.
нет первичного SDK-токена. У Telegram эта проблема закрыта много лет назад через
api_id/api_hashв MTProtoКак это должно помочь против атаки через веб, когда юзер вводит креды в полностью подконтрольном хакеру SPA? Даже, если хакер ходит якобы из под прилы, он сгенерирует себе валидный токен и подставит в проксируемый запрос. Потом с этим же токеном пойдёт работу работать, получив сессионный токен
send-code— нет привязки выпущенной SMS-сессии к идентичности устройства, инициировавшего ввод (TLS JA3/JA4 fingerprint, device id, web-cookie)Вообще из другой оперы. Это все имеет смысл, когда у юзера по-тихому сперли токен, полученный полностью легитимно (например, через взломанное расширение). Когда сессия делается хакером, у него все совпадет. Он будет юзать ту же сессию для этого аккаунта со всеми нужными параметрами.
Бэкенд кита делает сотни запросов в день на разные номера с одного IP
Откуда такая информация? Админ макса поделился логами? Оттуда уверенность, что хакер не используют прокси, или симбокс со сменой ип через реконнекты?
0x22
01.05.2026 05:52Знаете, я как-то дал ИИ некоторые свои наработки по багам, они совершенно не критичны, но в массе могли бы дать мелкий импакт в связке с чем-то, думал он чуть систематизирует, но он же пошёл дальше и выдал крит на 9+, ещё и отчёт забацал. Так и здесь видимо.
riky
01.05.2026 05:52да, тоже заметил. ИИ тут постарался из ничего прям триллер сделал :) лучше бы с помощью ИИ сделали скрипт который жалобы подает ежедневно на новые ип хостерам.
или скрипт запустили типа for (i = 7900_000_0000; i < 7999_999_999; i++) fetch(/send-code/…)
с домена мошейников. ну и самому роутер перезагружать чтобы ип менялся :) никаких проксей им не хватит, макс тогда реально начнет их банить… а если не начнет банить то все юзеры начнут получать смс и дело получит огласку.
sansmaster Автор
01.05.2026 05:52спасибо за коммент по большинству пунктов согласен
да Origin/Referer прокси подставит что хочет это работает от CSRF а не от server-to-server проксирования тут моя ошибка
по SDK-токену тоже прав статический api_id вытаскивается из APK за пять минут сам по себе он ничего не даёт . работает только в связке с app attestation - Play Integrity у гугла или DeviceCheck у эпла . вот этот токен серверный бот атакующего получить не сможет потому что гугл и эпл проверяют что есть реальное устройство и подлинная подпись приложения . без attestation вызов /api/send-code просто не должен проходить . писать надо было сразу про attestation а не про SDK-токен в общем
JA3/JA4 как session-binding да не работает согласен атакующий сам и есть initial-клиент у него всё совпадёт . но как сигнал на стороне max смысл какой то есть когда один fingerprint лезет на десятки разных номеров за час это паттерн прокси-кита а не нормального юзера . но это уже anomaly detection а не привязка тут ты тоже прав я в отчёте смешал две разные штуки
про "сотни запросов в день с одного ИП" - честно гипотеза . логов max у меня нету подтвердить не могу . оператор вполне может крутить через резидентские прокси или симбокс с реконнектом тогда ИП будет постоянно новый . так что рейт-лимит по сорс ИП реально не панацея нужен лимит по таргет-номеру (один телефон не получает смс чаще например пяти раз в час) и тут уже сложнее обойти
если совсем коротко суть не в этих мерах по отдельности . api max не проверяет что /api/send-code зовёт реальное приложение max а не левый сервер . из этого растёт вся атака кто угодно поднимает прокси-фронт юзер вводит номер прокси проксирует запрос в реальный апи max шлёт настоящий смс юзер вводит код прокси проксирует код получает sessionToken заходит в аккаунт . cloud password проксируется через /api/sign-in-2fa тем же способом 2фа не помогает
реально закрывают это только две вещи
первое app attestation на /api/send-code . серверный бот аттестейшен от гугла/эпла не получит ему нечем подтвердить что он реальное приложение
второе push-confirmation в активные сессии при попытке нового входа как у телеги whatsapp signal . даже если каким то чудом attestation обошли без подтверждения с уже активного устройства жертвы новая сессия не выпускается
всё остальное (Origin SDK-токен в одиночку JA3-привязка IP-лимиты) слабые меры тут ты прав . спасибо что разобрал внимательно сам бы не заметил часть слабостей
akakoychenko
01.05.2026 05:52То есть, все сводится к тому, что в ядре системы антифрода надо опираться на 2 американских сервиса, и, если они говорят, что в морг - значит в морг. Вроде, создатели макса чуть с другим посылом прилу создавали, не?
sansmaster Автор
01.05.2026 05:52)) Надеюсь нет. Я просто пример привел . чтобы гарантированно исключить такую уязвимость нужна двухфакторная аутентификация , в рф есть например Яндекс ключ ,но я считаю что для сервиса через который можно получить доступ в госуслуги необходим уровень безопасности даже лучше чем гугл аутентификатор , но тут нет даже его (подобного сервиса и ключами)., хотя бы Яндекс бы ключи подключили из того что уже есть . Но конечно нужен уровень безопасности выше.
kunix
01.05.2026 05:52app attestation на /api/send-code
Не понимаю, о чем тут идет речь?
Я только слышал про hardware-backed key attestation.
Это серьезная хрень, которая требует аппаратной поддержки в SoC (TrustZone и аналоги) и серьезной инфраструктуры для attestation key provisioning. То есть не стоит ожидать, что в дешевом китаефоне это будет работать.В любом случае все обходится фермой смартфонов.
В худшем случае у мошенника лежит тупо нерутованный смартфон под управлением ИИ, который тапает по экрану и делает логин. Да, наверное это дорого. Но теоретически возможно.
4external
01.05.2026 05:52app attestation - Play Integrity у гугла или DeviceCheck
а если хочется использовать web.max.ru?
Lavshyak
01.05.2026 05:52это и вставь в статью. а то я жоско комментировал комментарии ниже мол всё фигня.
Persik1
01.05.2026 05:52Ого, национальный мессенджер с интеграцией госуслуг не проверяет, откуда к нему стучатся за смс-кодом авторизации! Какая неожиданность. Зато наверное кучу сертификатов от ФСТЭК получили
Tomasina
01.05.2026 05:52Этот "национальный" мессенджер принадлежит физлицу, а банковские счета не в России.
Lavshyak
01.05.2026 05:52Наброс. Хацкеры вполне могут арендовать кучу прокси серверов или VDS в разных регионах РФ и с основного бэкенда проксировать на близжайший к пользователю. Пользователь и не увидит ничего необычного в "авторизированных устройствах". В том числе из-за этого и замедляют впны всякие.
IgnatF
01.05.2026 05:52Не буду Максим защищать. Ну думаю тут еще и сами пользователи должны быть внимательны. Не переходить по всяким ссылкам. А то есть такие, которые еще сами мошенниками наберут и код с смс отправят.
teraniel
01.05.2026 05:52Проблема в том что всякие бабушки и не особо технически подкованные личности верят зомобоящику, из которого трубят целыми днями что скаМ это идеальный безопасный мессенджер, где нет никаких плохих дядь и злобных украинских мошенников, которые удаленно взорвут их телефон. И потом показывают пальцем на телеграм и ватсап, что типа там это есть.
Поэтому у среднестатистического зрителя российского ТВ даже мыслей не возникает что в его идеальном приложении кто-то может пытаться его обмануть.
Wesha
01.05.2026 05:52Не буду Максим защищать
И не надо — он не Максим, а Мах (как в слове МАХОВОЙ).
Делай раз:
(Источник: https://legal.max.ru/ps) Делай два:
(источник: там же, чуть ниже) Делай три:
Товарищ
СталинПутин! Произошла чудовищная ошибка!
jahma48
01.05.2026 05:52Если кто-то из VK security всё же прочитает: контактный канал — личка на Хабре, готов ко всему — телефонный созвон, передача полного списка 179 доменов, выгрузка кода кита, координация с CERT-партнёрами. Полный отчёт с CVSS, PoC и рекомендациями уже у вас в
support@max.ru. Coordinated disclosure window — стандартный 90 дней.Можно, а зачем?
ViskasSP1vom
01.05.2026 05:52Прошла неделя. Ни одного ответа
Добро пожаловать в энтерпрайз. Пока об этой дыре не напишут в крупном тг канале с тегом гендиректора VK, ваш отчет будет мариноваться на первой линии техподдержки между жалобами на забытый пароль и спам
Spiritschaser
01.05.2026 05:52Я не уверен, что эта статья заставит VK что-то сделать
Почему, есть стандартная процедура: вы будете привлечены как злой хакер, подрывающий государственность РФ. С отрядом СОБР и СИЗО.
sansmaster Автор
01.05.2026 05:52возможно вы правы. Самое интересное что группа которую я описал по прежнему работает и сегодня сменили очередной хост .и меры никто не принимает .
edik-petrof
01.05.2026 05:52А почему их вообще пытаются ловить на уровне хостинга и ip адресов? Вот если бы им регистратор не просто разделегировал, а отозвал регистрацию всех 179 доменов разом, тогда и все ссылки вида
clk1.me/rD7P5Eавтоматически бы протухли. Рассылка спама в итоге сработала бы вхолостую с необходимостью начинать всё заново. Иначе эти кошки-мышки можно продолжать бесконечно.
KseandI
01.05.2026 05:52О да, легендарный api_id, который защищает ТГ от митмов, фишингов, вирусов, 0day’ев и, наверное, от рака.
Естественно тебе из макса не ответили, у тебя уяза уровня “помогите, я сказал скамерам логин, пароль и двухфакторку и теперь они получили доступ к моему аккаунту!”. Вот чем технически отличается фишинговый сайт от комментариев на хабре, куда ты напишешь свой логин и пароль? Что мне помешает взять эти данные и зайти в макс? А в ТГ? Госуслуги, приложение банка? Неужели они все уязвимы аж на целых 8.8 cve?! Срочно иди пиши всем репорты!
Иногда стоит смириться, что если ты не можешь запомнить, как выглядит адрес нужного тебе сервиса и понять, что только на нём надо вводить логин пароль от этого сервиса, то лучше просто не переходить по случайным ссылкам. Ну или по брейнштормить нейронку, что написала эту статью, раз api_id так хорошо помогает против фишинга, почему его нигде не используют.
arch1lochus
01.05.2026 05:52лучше просто не переходить по случайным ссылкам
лучше не наделять обыкновенный уязвимый мессенджер функцией подтверждения всего что угодно, включая кредиты, и не врать, что он безопасен даже для технически безграмотных бабушек. Мне это кажется самым полезным выводом из статьи
NikaLapka
01.05.2026 05:52Кому лень читать простыню - автору прислали шорт-кат, который ведёт на поддельную форму авторизации в максе. Простая компьютерная гигиена - смотри на адрес в адресной строке, но автор разлил воды не хуже рент-тв.. странно, что "иностранный" след ещё не нашёл..
sansmaster Автор
01.05.2026 05:52все верно . иностранный след нашел но это не суть статьи . спасибо за резюме ( не ирония)
valera_efremov
01.05.2026 05:52Цифровой свободе России на пользу, что репутация "безопасного", "национального" мессенджера будет разрушена мошенниками.
ideological
01.05.2026 05:52Не открывай на основном устройстве
Почему опасно открывать такую ссылку?
Достаточно сверять домен при авторизации.
Dobry_Latte
01.05.2026 05:52Пользователи Маха конечно же будут всегда сверять домен при авторизации. Все 50 миллионов.
Sergdesign
01.05.2026 05:52Очень актуально и своевременно, похоже, что эпидемия как раз в разгаре.
Только вчера получил пару таких сообщений от своих же контактов
Ссылка только link.ok.ru/htg и так далее
SagePtr
01.05.2026 05:52Очень забавно это сочетается с заявлением МВД о том, что опасные ссылки за пределами зоны .ru
Dobry_Latte
01.05.2026 05:52У них есть несколько вариантов действий. Можно наказать вас и заставить все опровергнуть и удалить. Можно пригласить вас в качестве стороннего тестера на договоре. Можно закрыть дыру и сделать вид, что ничего не заметили. И наконец, объявить, что они неправы. Как вы думаете, какой вариант исключен?
BareDreamer
01.05.2026 05:52Статья очень увлекательная. Однако, я задал вопрос ИИ-консультанту: является ли указанная проблема уязвимостью сайта? Он ответил, что это не уязвимость, поскольку проблему невозможно решить исправлением кода.
Lavshyak
01.05.2026 05:52Мда чел проверка origin никак не спасет, хацкеры тупо укажут в origin оригинальный домен фронтенда макса при запросах с ихнего бэкенда. И telegram никак не защищен от такой атаки со своим appid, собственно кастомные клиенты телеги указывают оригинальный appid телеграмма. В общем max ничего с этим поделать не может. Максимальной трудностью для хацкеров может быть только адская слежка, мол как клиент реагирует на что-либо, куда пользователь нажимает, частые обновления клиента и закрытого api; у недолюбливателей макса попа лопнет от такого.
В целом это MITM атака и виноват в ней пользователь, доверившийся левому домену.
muradali
01.05.2026 05:52Часто слышу по телевизору или от знакомых — "я нажал на ссылку и у меня украли доступы...". Начинаешь разбираться — он нажал, ввел телефон, получил код, ввел его.
Возможно у моссада в подземных лабораториях и есть 0 day уязвимости, которые при заходе по ссылке могут хакнуть браузер. Но такие штуки не будут использовать для массового угона аккаунтов, поскольку такую редкую уязвимость нужно держать в секрете.
Короче, можно сказать что не существует такого понятия как "нажал на ссылку и все украли". Но по телевизору, для обывателя, конечно лучше упростить — "не нажимайте на незнакомые ссылки а то все украдут"
Daddy_Cool
01.05.2026 05:52Иногда... некоторые граждане занимаются виктиблеймингом, типа сам установил Макс - сам виноват.
Вот история, женщина... 85 лет, банковских приложений не стоит, телефон под контролем взрослого сына, мошенники несколько раз звонили, но всегда посылались лесом. Пытается созвониться с племянницей в другом городе и переслать ей фотки, ТГ не работает, WA не работает, IMO у племянницы не стоит... племянница говорит, а поставьте Макс... и наша героиня переходит по ссылке и ставит Макс. И так-то оно вроде и ничего страшного, всё работает, но вот нарваться на MITM-атаку не хотелось бы.
kneaded
01.05.2026 05:52Не в тему, но в то же время в тему. Когда был 2024 год я говорил что к концу 2025 начнут резать фонд оплаты труда и настанет кризис в ИТ. Ну понятно, что со сроками не угадал - это произошло массово в в первые 3 месяца 2026 года.
Теперь же я сижу и говорю - они порезали самых сильных инженеров, оставили волков и слабых по компетенциям. Почему? Потому что они тупо меньше денег жрут. Они же, эти слабые, менеджерам пыль в глаза пускают какие они крутые и переделывают найм (на самом деле превращают в экзамены с тупыми вопросами и ответами), на самом деле его ломая.
Они же создают среду, где тяпляп и в продакшн. На безопасность плюют, ведь ИИ им об этом не сообщает. И усиливают эту среду - набирая таких же.
Вк этим грешит. И вот результат. Жду когда в 2027 году менеджеры снова вспомнят о дорогих специалистах и вспомнят почему они дорогие и наймут разгребать эту кучу гона. Эта куча рвзгребется хорошо если к концу 2027.
Автор молодец что озвучил такую проблему, однако ждать решения от вк лично я бы не стал - они заняты блокировками VPN и внедрением Макс на МКС и вообще куда угодно, потому что щас важнее деньги компании им а не деньги населения
Wesha
01.05.2026 05:52Они же создают среду, где тяпляп и в продакшн. На безопасность плюют, ведь ИИ им об этом не сообщает. И усиливают эту среду - набирая таких же.
А Вы помните фильм The Net 1995 года? Ну, тот, где сервера командой
pingвзламывали. А мы ещё смеялись...
VADemon
01.05.2026 05:52https://www.itnews.com.au/news/microsoft-patches-include-two-bugs-already-exploited-592075
CVE-2023-23415 looks like a “ping of death”.
It’s an ICMP remote code execution (RCE) bug with a CVSS score of 9.8, and would be exploited by sending a fragment inside another ICMP packet to the target.
Successful exploitation needs an application on the target to be bound to a raw TCP/IP socket.
ForRead
01.05.2026 05:52Слушайте , ну ощущение , что в ВК - Мах сидят одни дилетанты - это же далеко не так ? Все там разработка прекрасно понимает, как работает их авторизация. Это ровно та же история , что и с М-Видео, есть несколько сйтов полных копий основного онлайн-магазина.
IndyCar
01.05.2026 05:52согласен, хотя мы их кухни не знаем, и "дилетантизм" может оказаться в самом неожиданном месте. Самое плохое в подобной ситуации не реагировать более 90 дней на реальную проблему для приложения с миллионами пользователей...
Wesha
01.05.2026 05:52Слушайте , ну ощущение , что в ВК - Мах сидят одни дилетанты - это же далеко не так?
Не так! Они там не одни. Там ещё уборщица есть.
0x22
01.05.2026 05:52На техническом ресурсе, в разделе Информационной безопасности - люто заплюсованный пост-нейротрэш, не имеющий с ИБ ничего общего. Это обычный фишинг, его не могут устранить разработчики. Почитав комментарии, видя реакции на них в виде стрелочек вверх и вниз, становится понятно, что идёт ответка на впаривание маха. Проблема только в том, что попытки его очернить в данном посте, это не уровень ИБ, это для Пикабу. Вот если бы технически подкованный, реальный багхантер раскопал багу и так вот поставил на место разарабов маха, то да, но для этого есть ББ-площадки, а на "Хабр уже не торт" можно скидывать нейрослоп.
DrMefistO
01.05.2026 05:52Вне зависимости от того, какую оценку CVSS реально можно набрать на такой вулне, как минимум, в статье подсвечено, что в саппорте вк молчат и не считают нужным хотя бы сказать: "репортер - лох, не кликай по левым ссылкам, и другу своему скажи. И Вы не правы - тут не вулна, а фича".
0x22
01.05.2026 05:52Видите ли какое дело, на том же Standoff BB триажеры запарились получать сгенерированные ИИ-отчёты. Данный пост это типичное произведение ИИ. Думаю, получив такое, в саппорте и молчат. А кому отвечать, автору, что не удосужился перепроверить творчество нейронки и отправил разрабам "отчёт"? Тут же в комментариях автор пошёл назад пятками, разве нельзя было сделать это ДО отправки. Вот из-за подобных приходится ждать, пока триаж ответит, разобрав кучу нейрохлама в виде репортов. Это тоже и есть одна из причин, почему меня так зацепил данный пост, и те кто влепили мне в карму минус с подписью "Подозрительная активность", теперь знайте причину :)
DrMefistO
01.05.2026 05:52При прочтении статьи у меня такого ощущения не появилось. К тому же статья не равно отчёт. В статье написано, что автор писал отчёт по стандартам индустрии, на хабре же написана статья.
0x22
01.05.2026 05:52Это прям чересчур стандартные стандарты, их так нейронка и оформляет. Стиль автора в комментариях и статье - разница видна же. И главное - автор вообще будто не в теме о чём его же пост. В комментариях даже не пытался разъяснить, почему так он написал про Orgin, Referer тот же, а сразу говорит мол да, мой косяк.
VADemon
01.05.2026 05:52Устранить не могут, но иметь такую безалаберную аутентификацию и отсутствие поведенческих фильтров при открыто незашифрованном чате? Приложение хочет тесной интеграции с гос. сервисами. Это провал.
Насчет Хабра и его аудитории согласен.
valera_efremov
01.05.2026 05:52Автор, выложите список доменов, пожалуйста.
Нужно что то придумать, чтобы родители не смогли зайти на эти домены.
nerudo
Где virustotal показывает субдомены? Или кто их показывает?
Для бана на уровне хостера можно настроить ии-агента (это модно!), чтоб при смене хостера кидал жалобу
Нужно браузерное расширение, которое будет помечать свежезарегистрированные домены как подозрительные
rPman
Young Domain Guard
Recently Registered Domains
Real_Egor
Автоматические догонялки! Ваааааау =)
halted
По пункту 3. Что мешает нечистым на руку людям, создавать фейковые плагины для браузера? Вредоносных расширений навалом, сделать еще одно которое типа будет проверять (нет), не проблема ни разу.
Grey83
WOT есть много лет тот же: https://chromewebstore.google.com/detail/wot-website-security-safe/bhmmomiinigofkjcapegjjndpbikblnp