У цьому прикладі ми розглянемо фішингову кампанію, яка маскується під Netflix і використовує управління жертвою в режимі реального часу. Це не звичайна статична HTML-форма, а повноцінний phishing service: користувач проходить кілька етапів, а оператор із панелі управління вирішує, куди скерувати його далі — на введення логіна, картки, SMS-коду, PIN-коду або підтвердження в додатку.
Окремо ми підтвердили механізм через отримання доступу та вивчення панелі керування цим фішинговим сайтом.
У цій статті ми не описуємо спосіб отримання доступу до панелі, але використовуємо сам факт її наявності як підтвердження операційної моделі: атака керувалася вручну або напівавтоматично через backend-інтерфейс.
0. The Hook
Перше, що отримує користувач, — лист зі стандартною тактикою соціальної інженерії щодо необхідності вжити заходів. Зловмисники сподіваються привернути увагу користувача тим, що перегляд його улюблених телешоу може бути призупинено. Щоб обійти поштові фільтри та приховати кінцевий фішинговий домен, зловмисники використовують скорочене посилання через інфраструктуру соціальної мережі X: https://t.co/XXXXXXX
На перший погляд це звичайне посилання через t.co, тому вона виглядає менш підозріло як для користувача, так і для деяких автоматичних фільтрів.
Після кліка користувач не відразу потрапляє на основну фішингову сторінку. Спочатку його перенаправляють на проміжний ресурс.
1. Public S3 Bucket як проміжний редиректор
Посилання веде на публічний S3 Bucket: https://access-authority-2faXXXXX.s3.eu-north-1.amazonaws.com/index.html
Цей етап виконує роль фільтра та редиректора.
index.html Він містить фільтрацію за країнами та заздалегідь відомими IP-адресами. Це дозволяє не показувати справжній фішинговий сайт дослідникам, автоматичним сканерам, пісочницям та захисним системам.
Після проходження фільтра користувач отримує простий HTML-перенаправлення:
<meta http-equiv="refresh" content="1;url=https://www.XXXXX.help/index.html">
Домен маскується під сервіс для вирішення CAPTCHA. Це зручна легенда: користувач бачить технічну назву і може подумати, що перед ним проміжна перевірка браузера, CAPTCHA або security validation.
На практиці це фішингова інфраструктура.
Уже на цьому етапі проводиться фінгерпринтинг пристрою. Код збирає події користувача:
- mousemove
- touchmove
- keyup
- Backspace
- deviceorientation
Скрипт аналізує не тільки сам факт подій, але й їхні параметри:
- швидкість руху;
- інтервали між подіями;
- нормалізовані координати;
- різкість зміни напрямку;
- поведінку клавіатури;
- орієнтація пристрою;
- профіль дотику/миші.
Це використовується для оцінки того, чи є відвідувач реальною людиною.
Обфускація та «шифрування» телеметрії
Частина телеметрії перед відправкою шифрується за допомогою AES-CBC: crypto.subtle.encrypt({ name: 'AES-CBC', iv: ... }, key, data)
У коді є антидебаггова логіка. Скрипт збирає слово debugger з числового масиву та викликає його через new Function(). Якщо виконання затримується, сторінка надсилає beacon-запит на /misc/index.php?r=<random> з параметром bcl
Це схоже на спробу визначити, що користувач відкрив DevTools або що виконання JavaScript було зупинено на breakpoint; бекенд може змінити поведінку, приховати справжній потік і показати помилку або перенаправити користувача на легітимний сайт Netflix.
Після успішного проходження «капчі» відбувається перенаправлення на main/prepare.php
2. Перша фаза: збір логіна та пароля
Перший реальний етап атаки — це не картка і не SMS. Спочатку користувач потрапляє на сторінку, що імітує вхід у Netflix.
На цьому етапі зловмисники збирають електронну адресу та пароль.
Це важливо: атака починається з компрометації облікового запису, а вже потім переходить до платіжних даних.
Після відправлення POST-форми сторінка переводить користувача на наступний етап — «перевірку платіжної картки».
Таким чином, навіть якщо подальші кроки щодо оплати не будуть завершені, зловмисники вже отримують цінний результат: доступ до облікового запису.
3. Друга фаза: введення даних картки
Після введення логіна та пароля користувач перенаправляється на сторінку перевірки платіжних даних.
На цьому етапі сценарій імітує необхідність підтвердити картку, прив’язану до Netflix. Користувач бачить інтерфейс, схожий на легітимний billing-flow, і вводить платіжні дані.
Мета цього етапу — зібрати:
- ім'я власника картки
- номер картки
- дата закінчення терміну дії
- CVV/CVC
Під час цього процесу постійно надсилається телеметрія:
4. Третя фаза: екран завантаження та очікування оператора
Після введення даних картки користувач потрапляє на сторінку очікування. Саме цей HTML-код ми бачимо у дослідженому артефакті.
На сторінці зазначено:
Для завершення перевірки картки необхідна додаткова верифікація
Ви отримаєте коротке повідомлення на свій мобільний телефон...
Візуально це виглядає як звичайне очікування банківського підтвердження. Але технічно це не просто «екран очікування», це точка, де користувач залишається в сесії, поки backend або оператор вирішує, який наступний крок показати.
5. Управління в режимі реального часу через WebSocket
Головний механізм управління — WebSocket. Ми можемо помітити відкритий wss:// внизу запитів. Сторінка підключається до WebSocket і очікує команди від бекенду. У HTML закладена логіка, за якою оператор може перенаправити користувача на різні екрани:
| Код | Шлях | Опис |
|---|---|---|
| 1 | ./app.php | Сторінка запиту на підтвердження в банківському додатку |
| 2 | ./payment.php | Повторний запит на введення інформації про картку з помилкою |
| 3 | ./sms.php | Сторінка введення коду з СМС |
| 4 | ./pin.php | Сторінка введення пін-коду з картки |
| 5 | https://netflix.com | Перенаправлення на справжній сайт Netflix |
Картка, яку користувач вводить автоматично або в напівавтоматичному режимі, починає використовуватися для оплати в різних магазинах. Швидше за все, це підконтрольні зловмисникам торговці.
Саме тут компонент real-time стає особливо небезпечним. Оператор може бачити, який тип підтвердження запросила платіжна система, і адаптувати фішингову сторінку під конкретний момент атаки. Запитуючи то підтвердження в додатку, то код із СМС або ПІН-код з картки.
6. Підтвердження через admin-панель
Вивчивши роботу фішингового сайту, ми вирішили шукати вразливості цієї панелі. При цьому ми натрапили на досить дивні «пасхалки» від творця цієї панелі.
Згідно з логами можна стверджувати, що за 24 години щонайменше 4 різних адміністратори панелі входили в адмін-панель з інтервалом 4–7 годин.
Також ми виявили додаткові відкриті порти на панелі — 2082, 2095, 8880, 1010, які дозволили встановити справжню IP-адресу, адже сайт шахраїв знаходиться за CloudFlare.
Провайдери отримали повідомлення.
7. Індикатори компрометації
Домени
*.solvecaptcha.help
8. Висновок
Ця кампанія демонструє, як сучасні phishing services перетворюють звичайну сторінку входу на керовану операцію в режимі реального часу.
Зловмисники спочатку отримують логін і пароль, потім платіжні дані, після чого утримують користувача на екрані завантаження. У цей момент оператор із backend/admin-панелі вирішує, який наступний крок показати: SMS-код, PIN-код, підтвердження в додатку або фінальний редирект на справжній Netflix.
Головна технічна ознака цієї схеми — управління через WebSocket. Саме воно робить атаку інтерактивною та дозволяє операторам адаптувати сценарій під конкретну жертву та конкретний банківський потік.
Це вже не «фішингова сторінка». Це live phishing operation.