Дві ланцюжки атак 2026 року: викрадення платежів через реальні електронні листи

Дві ланцюжки атак 2026 року: викрадення платежів через реальні електронні листи 1

Компанія Gen Threat Labs дослідила дві кампанії першого півріччя 2026 року, під час яких зловмисники використовували легітимні облікові записи, налаштування браузера та дані блокчейну як частину ланцюжка атак.

Звіт Gen Threat Report — це дворічне дослідження найбільших кіберзагроз, що формують цифровий ландшафт, і воно пропонує глибокий аналіз тенденцій, які впливають на споживачів у всьому світі. Перший звіт Gen за перше півріччя 2026 року містить вражаючі цифри.

Шахрайство становило майже 46% виявлених загроз Gen у першому півріччі. Майже 30% припало на зловмисну рекламу. За цей самий період Gen заблокував 114,2 мільйона атак шахрайства в інтернет-магазинах та 20,3 мільйона атак шахрайства з технічною підтримкою.

Ці показники є корисними, але вони об’єднують дуже різні атаки в кілька категорій. Кількість виявлень не показує, як перший прийом призвів до виконання скрипта, як скрипт спричинив зміну налаштувань браузера чи проксі, або як адреса гаманця була замінена перед тим, як жертва підписала транзакцію.

Два розслідування першого півріччя заслуговують на детальний розгляд. У першому випадку кампанія банківського шкідливого програмного забезпечення почалася з компрометації корпоративних поштових скриньок і закінчилася маніпуляціями з проксі та браузером.

У другому випадку криптографічна кампанія використовувала кліпер на основі Rust і отримувала вказівники інфраструктури керування та контролю з Binance Smart Chain.

Використовувані шкідливі програми були різними, але жодна з кампаній не покладалася на порушення довіреної системи перед користувачем. Банківська кампанія використовувала легітимний обліковий запис для доставки приманки. Кліпер дозволив блокчейну записати дійсну транзакцію після локальної зміни адреси призначення.

Дві ланцюжки атак 2026 року: викрадення платежів через реальні електронні листи 2

Бізнес-електронний лист дійсно надійшов від бізнесу

Банківська кампанія була спрямована на користувачів у Чехії, Словаччині, Польщі та Литві. Приманки виглядали як звичайні ділові листи: повідомлення про відвантаження, листи щодо рахунків-фактур і сповіщення про скановані документи. В одному з них отримувачеві просто повідомили, що вкладено скановану копію відвантаження.

У кількох випадках повідомлення надсилалися з компрометованих корпоративних поштових скриньок. Лист не створювався так, щоб виглядати ніби від легітимної компанії. Він надходив з легітимного облікового запису, який зловмисники вже скомпрометували.

SPF і DKIM можуть пройти перевірку, коли повідомлення надсилається через авторизовану інфраструктуру, а системи репутації можуть побачити відправника з легітимною історією.

Вкладення запускало JavaScript-дропер. Звідти ланцюжок переходив через стадії PowerShell, перш ніж досягти оболонки та функціоналу банківського шкідливого ПЗ. Наявні індикатори вказували на GepyS.

Шкідливе ПЗ змінювало налаштування проксі та встановлювало розширення для браузера, наближаючись до банківської сесії жертви.

У спрощеному вигляді ланцюжок виглядав так: скомпрометована поштова скринька → JavaScript-дропер → стадії PowerShell → завантажувач оболонки → маніпуляції з проксі та браузером.

Один з корисних навантажень третьої стадії використовував 32-бітний завантажувач, незалежний від позиції. Статичний аналіз показав сміттєві інструкції MMX і SSE, стрибки в середину інструкцій і процедуру розшифрування на основі потоку ключів, згенерованого LFSR, з подальшим XOR.

Жодна з цих технік не була новою, але разом вони додавали достатньо перешкод, щоб швидкий статичний аналіз був менш продуктивним.

В рамках ланцюжка, електронний лист мав лише спонукати користувача відкрити вкладення. JavaScript і PowerShell відповідали за етапи, завантажувач сповільнював аналіз, а зміни в проксі та браузері переводили операцію в банківську сесію.

Порівнянні кампанії першого півріччя використовували подібні регіональні та операційні патерни з різними шкідливими програмами. В Італії фейкові PDF-рахунки, включаючи приманки в стилі Booking.com, вели до скриптів, розміщених на Vercel, зі скриптованою JavaScript-обфускацією для кожного жертви, етапами PowerShell, розміщеними на Blogspot, та XWorm.

У Польщі фішинг з використанням рахунків-фактур доставив .NET-завантажувач зі стеганографією, який встановив Remcos RAT.

Прочитайте звіт Gen H1 2026 Threat Report

Gen Threat Labs проаналізував активність першого півріччя 2026 року, яка включала шахрайство, шкідливе ПЗ, витік особистих даних, конфіденційність та загрози, спричинені ШІ.

Повний звіт містить телеметрію, приклади з реальних кейсів та рекомендації щодо того, як атаки проходять через довірені робочі процеси.

Read the report

Буфер обміну став платіжним рівнем

Друга кампанія зловживала набагато меншою взаємодією користувача: копіюванням і вставкою адреси криптовалюти.

Кінцевим корисним навантаженням був кліпер, скомпільований за допомогою Rust. Він відстежував скопійований вміст на предмет адрес гаманців у 21 типі блокчейнів, включаючи BTC, ETH і LTC. Коли шкідливе ПЗ розпізнавало підтримувану адресу, воно замінювало її на контрольовану зловмисником.

З точки зору жертви, транзакція могла виглядати нормально: скопіювати адресу, вставити її в гаманець або на біржу та підтвердити платіж.

Блокчейн не був скомпрометований, а криптографія гаманця не була зламана. Сама транзакція була дійсною, але призначення вже було локально змінено перед підписанням.

Адреси гаманців — це довгі, візуально шумні рядки, які важко перевірити людині. Багато користувачів перевіряють лише перші та останні кілька символів, що дає зловмисникам простір для використання адрес заміни, які проходять швидкий огляд.

Дизайн керування та контролю додав ще один рівень. Шкідливе ПЗ використовувало Binance Smart Chain як частину свого розділення C2 через EtherHiding. Воно не зберігало повний бекенд в мережі. Натомість воно читало вказівники інфраструктури з даних, що зберігаються в смарт-контракті, і використовувало їх для доступу до інфраструктури, контрольованої зловмисниками.

Розділений домен, URL або IP-адреса могли бути заблоковані, вилучені або замінені. Дані смарт-контракту залишалися публічно доступними для читання, що корисно як для розслідувального аналізу і їх важче видалити за допомогою звичайних процесів припинення.

Таким чином, простий список мережевих індикаторів компрометації (IoC) швидко застарівав у цій системі.

Адреса контракту, метод, використаний для читання його даних, повернуте значення та інфраструктура, досягнута після цього, належали до одного розслідування.

Виявлення повинно відповідати послідовності

Для банківського ланцюжка автентифікація відправника повинна бути поєднана з телеметрією після доставки. Запуск JavaScript вкладенням, отримання PowerShell додаткових етапів, виконання оболонки, зміни проксі та новий додаток для браузера слід корелювати як одну послідовність, а не обробляти як непов’язані події.

Легітимна історія відправника не повинна знижувати пріоритет цієї активності, коли сама поштова скринька може бути скомпрометована.

Де це операційно можливо, організації можуть обмежити скриптові інтерпретатори для користувачів, яким вони не потрібні, застосувати політики контролю додатків до завантажених вкладень та сповіщати про несподівані зміни проксі або розширень браузера.

Моніторинг компрометації поштових скриньок залишається частиною тієї ж проблеми виявлення, оскільки скомпрометований обліковий запис також є інфраструктурою доставки.

Для криптографічної кампанії захисники можуть моніторити процеси, що змінюють буфер обміну, зіставлення шаблонів адрес гаманців та запити блокчейну від додатків, які не мають причин їх робити. Вказівник смарт-контракту та інфраструктура, яку він визначає, повинні відстежуватися разом, замість того, щоб розглядати поточний домен C2 як повний набір індикаторів.

Користувачі, які здійснюють криптовалютні платежі, повинні перевіряти повну адресу призначення, показану пристроєм підписання або гаманцем, безпосередньо перед схваленням.

Адресні книги або списки дозволів зменшують повторний ручний ввід, тоді як призначення, що вводяться вперше або змінюються, заслуговують на повне порівняння, а не на перевірку лише початкових і кінцевих символів.

В обох кампаніях перше рішення про довіру могло виглядати легітимним, тоді як навколишній робочий процес вже був змінений. Виявлення та верифікація повинні охоплювати кроки між автентифікованим електронним листом, скопійованим значенням та фінальною дією.

Звіт Gen’s H1 2026 Threat Report охоплює ширшу картину шахрайства, шкідливого ПЗ, витоку особистих даних, конфіденційності та загроз, керованих ШІ.

Прочитайте повний звіт тут: Gen H1 2026 Threat Report.

За спонсорської підтримки та написання Gen Digital.

  • Банківський троян
  • Криптовалюта
  • Кібербезпека
  • Gen Digital
  • Фішинг
  • Звіт про загрози
  • Попереднє стаття
  • Наступна стаття

Інформація підготовлена на основі матеріалів: www.bleepingcomputer.com

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *