Анатомия современного фишинг-кита: от "дружеского" сообщения в мессенджере до bulletproof‑хостинга на сотнях доменов
---
14 марта 2026 года в личный Telegram приходит сообщение от знакомого:
> Салам Аллейкум братья и сестры
> Проходит региональное голосование
> Прошу проголосовать за меня и отправить по своим
Внизу - ссылка: `beaminkjet[.]com/umarashab`.
Фраза "отправить по своим" здесь критична: каждую новую жертву мгновенно превращают в канал распространения для её контакт-листа. Сообщение отправлено с реально существующего, но уже скомпрометированного аккаунта, поэтому уровень доверия максимальный. В итоге получается классический вирусный фишинг без использования эксплойтов: весь успех кампании строится на социальной инженерии и грамотно выстроенной технической инфраструктуре.
Ниже - подробный разбор этой атаки: от первой фишинговой ссылки до устройства сервера и инфраструктуры на 290+ доменов. Материал ориентирован на SOC-аналитиков и специалистов по threat intelligence: внутри - IOC, техники обфускации, особенности инфраструктуры и идеи для правил детекции (Sigma, YARA), а также привязка к MITRE ATT&CK.
---
Цепочка атаки: три этапа
Атаку можно условно разделить на три последовательных шага:
1. Фильтрация трафика - отделение реальных жертв от ботов и аналитиков.
2. Имитация голосования - создание правдоподобного повода "авторизоваться".
3. Кража сессии Telegram - получение полного контроля над аккаунтом и дальнейшее распространение.
Каждый этап продуман и технически подкреплён: от User-Agent-фильтрации до полиморфного CSS и одноразовых токенов в URL.
---
Этап 1. Фильтрация: кто увидит фишинг, а кто - нет
Первое, что делает сервер при обращении к ссылке, - анализирует заголовок `User-Agent`. В зависимости от типа клиента поведение радикально меняется:
- Мобильный браузер
Ответ: `200 OK` и выдача фишинговой страницы.
Цель: показать атакующий контент целевой аудитории (людям со смартфонов, пришедшим по ссылке из мессенджера).
- Десктопный браузер
Ответ: `302 Redirect` на `google.com`.
Цель: скрыть фишинг от аналитиков, которые часто проверяют подозрительные URL с рабочего ПК.
- TelegramBot и другие "просмотровые" боты
Ответ: `204 No Content`.
Цель: не генерировать превью в мессенджере и не подсвечивать ссылку автоматическими сканерами.
То есть фильтрация построена осознанно: любой автоматизированный или "нетипичный" клиент либо видит безобидный ресурс, либо вообще не получает содержимого. Реальная фишинговая страница показывается только тем, кто максимально похож на живого пользователя с телефона.
---
Этап 2. "Голосование" как приманка
Мобильный пользователь попадает на страницу псевдорегионального голосования. Интерфейс выглядит правдоподобно:
- два кандидата с фотографиями (картинки физически находятся на стороннем хостинге изображений),
- счётчики голосов рядом с каждым,
- крупная кнопка "Проголосовать".
После нажатия по кнопке всплывает окно:
> В целях борьбы с накруткой просим вас авторизоваться с помощью соц. сетей.
Единственный доступный вариант - "Войти через Telegram". По клику жертву перенаправляют на следующую страницу - уже с поддельным Telegram Login Widget, имитирующим официальный механизм авторизации.
---
Этап 3. Кража сессии и захват аккаунта
Фейковый виджет Telegram предлагает ввести:
- номер телефона;
- полученный в SMS/клиенте код авторизации.
Всё выглядит достаточно правдоподобно: оформление, структура формы, тексты - максимально близки к легитимным. Но введённые данные сразу уходят злоумышленникам. Получив код, они моментально авторизуются под жертвой в Telegram-клиенте или API и получают:
- полный доступ к переписке;
- список контактов;
- управление каналами и чатами;
- возможность рассылать такие же фишинговые сообщения "от имени" уже скомпрометированного пользователя.
Так обеспечивается экспоненциальный рост заражения: каждый новый аккаунт становится рассылочным центром для своей сети контактов, что многократно увеличивает охват кампании без необходимости взламывать инфраструктуру Telegram.
---
Гомоглифы: незаметная подмена символов для обхода текстовых фильтров
Текст фишинговых страниц выглядит на первый взгляд абсолютно обычным: "голосов", "проект", "участие" и т.п. Но если внимательно посмотреть на байтовое представление, окажется, что часть кириллических букв подменена визуально идентичными латинскими. Например:
- "гoлocoв" - латинская `o` вместо кириллической `о`,
- "прoeкт",
- "учacтиe" и другие подобные вариации.
Глазу пользователя такая подмена незаметна, а вот текстовый фильтр, ориентированный на кириллические слова, эти фразы уже не распознаёт. Поиск по обычному "голосов" не обнаружит "гoлocoв", в котором символы принадлежат другому алфавиту.
Этот приём известен как атака гомоглифами и в MITRE ATT&CK описан в технике T1036.005 (Masquerading). Классически там речь идёт о маскировке файлов и процессов, но здесь та же идея перенесена на уровень контента: текст маскируется под "похожий", чтобы уйти от контент-фильтрации в мессенджерах и почтовых системах. Это нетривиальное применение техники, на которое стоит обращать внимание при настройке детектов.
---
Полиморфный CSS: динамическое изменение классов
Каждый HTTP‑запрос к фишинговой странице приводит к генерации уникального набора CSS-классов. Схема следующая:
- для всех CSS-классов создаётся единый 8-символьный префикс;
- к нему добавляется устойчивый суффикс, например `_LtqiE`.
В результате классы на странице выглядят примерно так:
- `ab12cd34_LtqiE`,
- `ab12cd34_LtqiE_flex`,
- и т.д.
При следующем обращении префикс будет уже другим (например, `k9x3lm7p_LtqiE`), но суффикс `_LtqiE` сохранится. Обфускация реализована на стороне PHP-шаблонизатора: классы подставляются в HTML и CSS динамически.
Для сигнатурного детекта это означает следующее:
- бессмысленно ловить конкретные названия классов целиком - они меняются каждый раз;
- вместо этого стоит искать устойчивые части, вроде типовых суффиксов.
Отдельная техническая деталь: SVG-иконки Telegram, встроенные инлайном, содержат фиксированный префикс `ojmcdqfn_`. Очевидно, шаблонизатор не обрабатывает inline‑SVG, и этот элемент может служить дополнительным признаком фишинг-кита.
---
CSS-мусор: атака на автоматический анализ
Практически каждый CSS-блок на странице содержит "мусорные" свойства, которые затем переопределяются реальными. Пример логики:
- сначала задаются одни значения (цвета, размеры, шрифты);
- далее в том же классе или в более специфичном селекторе эти значения перезаписываются корректными.
Если анализировать только "первый слой" CSS без учёта каскадности и приоритетов (как это нередко делают простые автоматические сканеры), картина стилей будет выглядеть хаотичной и неконсистентной. По сути, это приём для:
- усложнения статического анализа;
- запутывания эвристик, пытающихся по стилям распознать шаблон фишинга;
- создания "шума", затрудняющего построение устойчивых сигнатур по оформлению страницы.
---
Anti-replay токены и уникальные пути
Для каждого запроса фишинговый сервер генерирует собственные идентификаторы:
- `base href` содержит путь, похожий на SHA‑256 хеш, например `/5c02cd685e88686d...`;
- путь редиректа включает 7-символьный токен вида `am4DHt2`, `vg0uJod`, `c4329mf`.
Такой URL одноразовый: повторный переход с тем же токеном сервер больше не принимает - запрос отклоняется. Это даёт сразу несколько эффектов:
1. Сложнее анализировать вручную: аналитик, сохранивший ссылку из логов, при повторном заходе может уже не увидеть исходную страницу.
2. Затруднено массовое сканирование: каждый запрос sandbox-инфраструктуры к одному и тому же базовому URL получает новую уникальную страницу и токен.
3. Снижение эффективности обмена IOC: простое распространение одного конкретного URL даёт ограниченный эффект, потому что кампания активно использует множество одноразовых маршрутов.
Для детектирования в таких условиях полезно переходить на более абстрактные признаки: структуру путей, характерные параметры, поведение при разных User-Agent, а не опираться только на конкретные конечные URL.
---
Мусорный HTML: маскировка под интернет‑магазин
Существенная часть HTML-кода фишинговой страницы физически не отображается пользователю. В разметке присутствуют многочисленные `div` и другие элементы с `display: none`. Внутри:
- фиктивные товары вида:
"Luxurious Metal Table - 294.52$";
- бессмысленный "латинский" текст по типу:
"Vilicus iure thorax a.";
- псевдо‑таблицы с датами, суммами и заказами;
- формы с `input`‑полями, имитирующие корзину и оформление заказа.
Задача всего этого "мусора" - сбить с толку антифишинговые сканеры, которые смотрят на структуру страницы и пытаются классифицировать её как форму входа, банковский сервис, лендинг и т.п. Благодаря скрытым элементам страница по совокупности признаков больше похожа на интернет-магазин, а не на сайт, ворующий Telegram-сессии.
---
Tracking-хеш в комментариях
В HTML-комментариях постоянно повторяется одинаковое значение:
- `8d1c6e9b6c08132c9bddf5128515ebcc` (формат напоминает MD5).
Этот идентификатор не меняется между запросами, несмотря на полиморфный CSS и одноразовые токены в URL. Вероятнее всего, это:
- либо ID конкретной сборки фишинг-кита;
- либо идентификатор оператора или партнёра в рамках некой "аффилиейт‑программы" по фишингу.
Для аналитиков это полезный устойчивый признак, по которому можно:
- связывать между собой разные домены и страницы;
- выявлять общую принадлежность к одной кампании;
- строить YARA‑правила, ориентированные именно на этот маркер.
---
Инфраструктура: сервер и подсеть
Ключевые инфраструктурные параметры сервера, обслуживающего фишинг-страницы:
- IP‑адрес: `77[.]83[.]39[.]62`
- ASN:
- AS214940 KPRONET
- AS215693 PalmaHost
- Владелец сети / подсети:
Pitline Ltd, Харьков, Украина (`77[.]83[.]36[.]0/22`)
- Censys label: BULLETPROOF (confidence 0.75)
- Операционная система: Debian 12 (по данным SSH, OpenSSH 9.2p1)
- Веб-сервер: Caddy с пробросом на PHP‑backend
- SSL-сертификат: Let's Encrypt E7, выдан 14.03.2026 11:16 UTC
Соседние IP в диапазоне `77[.]83[.]39[.]x` имеют сотни жалоб на AbuseIPDB (например, `77[.]83[.]39[.]4` - 931 репорт). Это указывает на систематическое использование подсети для вредоносной активности: фишинг, спам, возможный хостинг malware.
Такие провайдеры обычно относятся к категории bulletproof‑хостинга: они закрывают глаза на злоупотребления или реагируют крайне медленно, что позволяет злоумышленникам держать инфраструктуру в рабочем состоянии дольше обычного.
---
Перестройка сервера и множество доменов
На одном и том же IP‑адресе обнаружилось как минимум 12 различных доменов, связанных с описываемой кампанией. Анализ WHOIS и данных Certificate Transparency показывает:
- домены регистрируются партиями;
- используются схожие шаблоны имён;
- сертификаты выпускаются автоматически и массово;
- домены "живут" относительно недолго и быстро заменяются новыми.
В сумме инфраструктура тянется более чем чем на 290 доменов, обслуживающих:
- различные фишинговые страницы;
- редиректоры;
- вспомогательные ресурсы (картинки, скрипты);
- промежуточные звенья в цепочке атак.
Такая масштабность и "одноразовость" доменов делают бессмысленной защиту, основанную исключительно на чёрных списках URL. Необходимо комбинировать:
- анализ сетевой принадлежности (подсети и ASN);
- поведенческие признаки;
- общие артефакты кода и шаблонов.
---
Масштаб кампании и её устойчивость
Комбинация факторов делает кампанию крайне живучей:
1. Вирусное распространение через доверие
Каждый захваченный аккаунт в мессенджере - источник новых жертв. Пользователи доверяют "другу", а не абстрактной рассылке.
2. Bulletproof‑инфраструктура
Расположение на подсетях с репутацией "грязных" и слабой реакцией на abuse‑репорты облегчает долгое существование фишинговых доменов.
3. Полиморфизм страниц
Изменяемые CSS-классы, одноразовые токены в URL, уникальные маршруты и мусорный HTML затрудняют разработку статических сигнатур.
4. Обход контент-фильтров
Гомоглифы в тексте и умная фильтрация по User-Agent прячут фишинг от автоматических систем проверки ссылок и превью в мессенджерах.
В совокупности это создаёт пример хорошо продуманной, промышленно организованной фишинговой операции, ориентированной не только на технический, но и на психологический успех.
---
IOC и направления детекции
С точки зрения защиты инфраструктуры и расследования инцидентов полезно опираться на несколько категорий индикаторов.
1. Сетевые IOC
- IP‑адреса (`77[.]83[.]39[.]62` и соседние в `77[.]83[.]39[.]0/24`);
- подсети и AS (`77[.]83[.]36[.]0/22`, AS214940, AS215693);
- характерная комбинация: Caddy + PHP + Let's Encrypt E7, активированные в одном временном окне;
- аномально большое количество сертификатов и доменов, привязанных к одному IP.
2. Контентные IOC
- повторяющийся MD5‑подобный хеш в HTML‑комментариях: `8d1c6e9b6c08132c9bddf5128515ebcc`;
- фиксированный префикс `ojmcdqfn_` в inline‑SVG-иконках;
- структуры HTML с большим количеством `display: none` блоков, содержащих "магазинный" контент и псевдолатинский текст;
- полиморфные CSS-классы с устойчивыми суффиксами типа `_LtqiE`.
3. Поведенческие IOC
- разное поведение одного и того же URL в зависимости от `User-Agent`:
- `200 OK` и фишинг при мобильном UA,
- `302` на общепринятый ресурс при десктопном UA,
- `204 No Content` для TelegramBot и подобных;
- одноразовые 7‑символьные токены в путях редиректа;
- хешеподобные сегменты в `base href`.
---
Детекция на уровне прокси-логов (Sigma)
Для логов прокси и шлюзов безопасности можно формализовать следующие сигналы для сигнатурных и поведенческих правил:
- Множественные обращения к одному домену с разным ответом по HTTP‑коду в зависимости от `User-Agent` или типа устройства.
- URL с необычными одноразовыми токенами: короткие (6-8 символов), смешанные буквы и цифры в пути, меняющиеся при каждом запросе.
- Подозрительные редиректы на крупные легитимные ресурсы (например, на стартовые страницы поисковых систем) при обращении с десктопа, но не с мобильного.
Sigma‑правила могут описывать такие комбинации и поднимать алерты при обнаружении статистически нетипичных паттернов для конкретной организации.
---
Детекция контента (YARA по HTML)
Для анализа HTML‑страниц (в прокси, песочницах или системах разборки вложений) YARA‑правила могут опираться на:
- наличие специфического хеша в комментариях (`8d1c6e9b6c08132c9bddf5128515ebcc`);
- повторяющиеся фрагменты псевдолатинского текста;
- сочетание:
- поддельной формы Telegram‑авторизации,
- множественных скрытых блоков `display: none` с товарами и ценами,
- полиморфных классов с общим суффиксом;
- inline‑SVG с фиксированным префиксом `ojmcdqfn_`.
Важно учитывать полиморфизм: правила должны быть устойчивы к изменению отдельных строк и классов, фокусируясь на трудноизменяемых элементах (структура формы, метки, статичные ID, повторяющиеся маркеры).
---
MITRE ATT&CK: связь с техниками
Кампания пересекается с рядом техник MITRE ATT&CK:
- T1036.005 (Masquerading: Match Legitimate Name or Location)
Используется для маскировки текста с помощью гомоглифов, что является нетипичным, но логичным переносом концепции маскировки на уровень контента.
- T1566 (Phishing)
Классический фишинг через социальную инженерию, дополненный вирусным распространением за счёт скомпрометированных аккаунтов пользователей.
- T1071 (Application Layer Protocol)
Использование веб‑протокола и мессенджера в качестве канала доставки и управления.
- T1105 (Ingress Tool Transfer) в расширенном понимании
Передача токенов и авторизационных данных через специально подготовленные веб-формы.
Привязка к MITRE позволяет встраивать наблюдаемые события в общую картину угроз и выстраивать защиту на уровне техник, а не только сигнатур.
---
Рекомендации по защите
Для SOC и IR-команд
1. Расширить мониторинг User-Agent‑зависимого поведения
Фиксировать ресурсы, которые по-разному отвечают мобильным и десктопным клиентам, особенно в корпоративном трафике.
2. Использовать сетевую контекстную блокировку
При подтверждении вредоносности отдельных IP/подсетей (`77[.]83[.]36[.]0/22`) рассматривать возможность их более жёсткой фильтрации на периметре.
3. Интегрировать контентный анализ для HTML
Внедрять YARA‑проверки на SMTP‑шлюзах, прокси и в песочницах с учётом описанных характерных артефактов.
4. Не ограничиваться только URL‑фильтрацией
С учётом массового использования одноразовых доменов и токенов важно строить детект по совокупности признаков: структуре HTML, поведению, принадлежности к подсетям.
Для IT‑безопасности и администраторов
1. Включить защиту сессий и двухфакторной аутентификации
Везде, где возможно, применять дополнительные факторы входа и отслеживать подозрительные авторизации с новых устройств и IP.
2. Организовать регулярное обучение пользователей
Объяснять, что даже сообщения от знакомых могут быть скомпрометированы; акцентировать внимание на необычных просьбах "проголосовать", "помочь", "скинуть код".
3. Настраивать блокировку входа по украденным сессиям
Реагировать на инциденты так, чтобы при первом подозрении можно было оперативно обнулить все сессии и принудительно перелогинить пользователя.
Для рядовых пользователей
- Никогда не вводить коды авторизации Telegram (или других сервисов) на сторонних сайтах, даже если ссылка пришла "от друга".
- Проверять доменное имя и протокол, особенно при входе в соцсети и мессенджеры через браузер.
- При малейшем сомнении связываться с отправителем по альтернативному каналу (голосом, другим мессенджером), чтобы убедиться, что аккаунт не взломан.
---
Фишинговые кампании уровня описанной выше демонстрируют, что злоумышленники активно комбинируют социальную инженерию с техническими приёмами обфускации, полиморфизма и bulletproof‑инфраструктуры. Простых средств защиты вроде "проверить ссылку" или "поставить антивирус" уже недостаточно: требуется комплексный подход, который соединяет в себе детект на сетевом уровне, анализ контента и грамотное обучение пользователей.
