Компанія Gen Threat Labs відстежила дві кампанії першої половини 2026 року, в яких зловмисники використовували легітимні облікові записи, налаштування браузера та дані блокчейну як частину атаки.
Звіт Gen Threat Report — це дворічне дослідження найактуальніших кіберзагроз, що формують цифровий ландшафт, та глибокий аналіз тенденцій, які впливають на споживачів у всьому світі. Звіт Gen за першу половину 2026 року містить низку вражаючих цифр.
Шахрайські схеми становили майже 46% виявлень загроз Gen у першій половині року. Майже 30% припало на шкідливу рекламу. За той самий період Gen заблокувала 114,2 мільйона атак через шахрайські інтернет-магазини та 20,3 мільйона атак з технічною підтримкою.
Ці показники корисні, але вони стискають дуже різні типи атак у кілька категорій. Кількість виявлень не показує, як початкова приманка призвела до виконання скрипта, як скрипт перетворився на зміну налаштувань браузера чи проксі-сервера, або як адреса гаманця була замінена перед тим, як жертва підписала транзакцію.
Два дослідження за першу половину року заслуговують на детальний розгляд. У першому випадку кампанія з банківським шкідливим програмним забезпеченням почалася з компрометації корпоративних поштових скриньок і завершилася маніпуляціями з проксі-сервером та браузером.
У другому випадку криптографічна кампанія використовувала кліпер (clipper), написаний на Rust, і отримувала вказівки для інфраструктури керування та контролю (C2) з Binance Smart Chain.
Використовувані шкідливі програми були різними, але жодна з кампаній не покладалася на зламування довіреної системи, яка знаходиться перед користувачем. Банківська кампанія використовувала легітимний обліковий запис для доставки приманки. Кліпер дозволив блокчейну записати дійсну транзакцію після локальної заміни адреси призначення.
Діловий лист справді надійшов від бізнесу
Банківська кампанія була спрямована на користувачів у Чехії, Словаччині, Польщі та Литві. Приманки виглядали як звичайні ділові листи: повідомлення про відвантаження, рахунки-фактури та сповіщення про отримані скановані документи. В одному з них одержувачу просто повідомлялося, що вкладено відскановану копію відвантаження.
У кількох випадках листи надсилалися з компрометованих корпоративних поштових скриньок. Лист не був створений так, ніби він надходить від легітимної компанії. Він надсилався з легітимного облікового запису, який зловмисники вже зламали.
SPF та DKIM можуть бути успішно пройдені, коли лист надсилається через авторизовану інфраструктуру, а системи репутації можуть бачити відправника з легітимною історією.
Вкладення запускало JavaScript-дропер. Далі ланцюжок переходив через стадії PowerShell, досягаючи оболонки (shellcode) та функціональності для банківських операцій. Доступні індикатори вказували на 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 року, включаючи шахрайські схеми, шкідливе програмне забезпечення, витік особистих даних, проблеми конфіденційності та загрози, керовані ШІ.
Повний звіт містить телеметрію, приклади випадків та рекомендації щодо того, як атаки проходять через довірені робочі процеси.
Прочитати звіт
Буфер обміну став платіжним рівнем
Друга кампанія зловживала набагато меншою взаємодією з користувачем: копіюванням та вставкою адреси криптовалюти.
Кінцевою шкідливою програмою був кліпер, скомпільований на 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