24.12.2025
5 хв
466
У цій статті розглядається, чому Interlock не варто сприймати як черговий «звичайний» шифрувальник. Йдеться про комплексний підхід до атак, у якому поєднуються соціальна інженерія, прихований доступ до систем, поступове розширення контролю та тиск на жертву після інциденту. Такий формат атак добре вписується в сучасну модель кіберзлочинності, де вирішальну роль відіграє не швидкість, а контроль і інформаційна перевага.
Аналіз показав, що атака мала багатоступеневий характер. На початковому етапі зловмисник розгорнув інструмент віддаленого доступу (RAT), замаскований під фальшиве оновлення браузера. Далі використовувалися PowerShell-скрипти, інструмент для викрадення облікових даних та кейлогер. Лише після цього було розгорнуто й активовано бінарний файл шифрувальника ransomware.
Для горизонтального переміщення мережею скомпрометованої організації зловмисник переважно використовував протокол віддаленого робочого столу (RDP). Крім того, застосовувалися й інші інструменти віддаленого доступу, зокрема AnyDesk та PuTTY.
Ексфільтрація даних здійснювалася за допомогою Azure Storage Explorer, який використовує утиліту AZCopy. Викрадені дані передавалися до Azure Blob-сховища, контрольованого атакувальником.
Аналіз часової шкали атаки від початкової компрометації до запуску шифрувальника свідчить, що зловмисник перебував у середовищі жертви приблизно 17 днів.
Існує припущення з низьким рівнем упевненості, що ransomware Interlock може бути пов’язаний із новою диверсифікованою групою, яка сформувалася на базі операторів або розробників Rhysida. На це вказує схожість у тактиках, техніках і процедурах (TTP), а також певні збіги в самих бінарних файлах шифрувальника.
Група Interlock вперше з’явилася у відкритих звітах у вересні 2024 року. Відтоді її пов’язують з атаками у стилі big-game hunting та застосуванням моделі подвійного вимагання. Зловмисники атакують організації з різних галузей, не обмежуючись якоюсь однією сферою.
Згідно з публікаціями на сайті витоків даних, серед цілей Interlock були компанії з секторів охорони здоров’я, технологій і державних установ у США, а також виробничі підприємства в Європі. Така географія й різноманітність жертв свідчать про опортуністичний характер вибору цілей – атакують тих, до кого вдається отримати доступ.
Як і багато інших угруповань у сегменті big-game hunting, Interlock веде власний сайт витоків даних під назвою Worldwide Secrets Blog. На ньому публікуються посилання на викрадені дані жертв, доступний чат для спілкування з постраждалими, а також вказана контактна електронна адреса для переговорів – interlock@2mail[.]co.
У своєму блозі Interlock заявляє, що атакує інфраструктуру організацій шляхом експлуатації невиправлених вразливостей. Угруповання стверджує, що його дії частково мотивовані прагненням притягнути компанії до відповідальності за слабкий рівень кібербезпеки, а не лише фінансовою вигодою.
Під час розслідування атаки з використанням ransomware Interlock було зафіксовано низку характерних тактик, технік і процедур, які зловмисник застосовував на кожному етапі ланцюжка доставки атаки. Аналіз показує, що атакувальник перебував у середовищі жертви приблизно 17 днів від моменту початкової компрометації до розгортання та запуску ransomware Interlock.
Зловмисник отримав доступ до комп’ютера жертви через фальшивий виконуваний файл оновлення браузера Google Chrome. Жертві було запропоновано завантажити це «оновлення» з легітимного новинного сайту, який на той момент був скомпрометований.
Після натискання на посилання файл під назвою upd_2327991.exe завантажувався на систему жертви вже з іншої скомпрометованої URL-адреси, що належала легітимному ритейлеру.
Під час аналізу було встановлено, що фальшивий файл оновлення браузера насправді є інструментом віддаленого доступу (RAT). Після завантаження і запуску він автоматично виконує вбудований PowerShell-скрипт.
На першому етапі цей скрипт завантажує легітимний інсталяційний файл Chrome під назвою ChromeSetup.exe до тимчасової папки застосунків на комп’ютері жертви. Паралельно з цим зловмисник налаштовує механізм постійної присутності в системі, створюючи ярлик Windows у папці автозапуску з назвою fahhs.lnk.
Цей ярлик налаштований так, щоб запускати RAT під час кожного входу користувача в систему, забезпечуючи зловмиснику стабільний доступ до скомпрометованого середовища.
RAT виконує команду cmd.exe /c systeminfo та збирає з комп’ютера жертви системну інформацію, зокрема такі дані:
Після цього RAT шифрує зібрану інформацію безпосередньо в потоці пам’яті. Далі він встановлює захищене сокет-з’єднання з сервером керування і контролю (C2), який прихований за доменом Cloudflare, контрольованим зловмисником, apple-online[.]shop. Зашифрований потік даних із системною інформацією жертви передається на C2-сервер, після чого RAT очікує на відповідь.
Також RAT надає зловмиснику можливість виконувати на скомпрометованій системі ще дві PowerShell-команди. За їх допомогою завантажуються зашифровані бінарні файли викрадача облікових даних cht.exe та кейлогера klg.dll. Після завантаження ці файли розшифровуються з використанням паролів jgSkhg934@kjv#1vkfg2S і запускаються в системі.
Було зафіксовано, що кейлогер є DLL-файлом, який запускається за допомогою легітимної системної утиліти rundll32.exe, що дозволяє замаскувати його виконання під звичайну активність Windows.
Під час розслідування було зафіксовано, що на частині скомпрометованих серверів у середовищі жертви було вимкнено EDR. За наявними індикаторами можна припустити, що зловмисник міг скористатися або спеціальним інструментом для деінсталяції EDR, або задіяти вразливий драйвер пристрою Sysmon.sys (TfSysMon.sys) для його відключення на системі жертви.
Також було помічено спроби зловмисника видалити вміст журналів подій Windows на окремих скомпрометованих системах, що свідчить про намагання приховати сліди своєї активності.
Викрадач облікових даних, виявлений у цій кампанії, скомпільований мовою Golang. Він перелічує встановлені профілі браузерів на комп’ютері жертви та копіює файли Login Data, Login State, key4.db, історію браузера і закладки до тимчасової папки профілю застосунків.
Після цього шкідливе ПЗ обробляє зібрані дані та за допомогою SQL-запитів витягує облікові дані до онлайн-акаунтів жертви разом із відповідними URL-адресами сервісів. У фінальній фазі вся зібрана інформація записується у файл chrgetpdsi.txt у тимчасовій папці користувацького профілю.
DLL-кейлогер, що працює на системі жертви, є невеликим виконуваним модулем. Він перехоплює натискання клавіш і записує їх у файл conhost.txt, який зберігається в тій самій директорії, куди було завантажено кейлогер.
Зловмисник виконував PowerShell-команди, які є відомими індикаторами розвідки перед Kerberoasting. Такий підхід зазвичай використовується для отримання облікових даних доменних адміністраторів.
Із середнім рівнем упевненості можна стверджувати, що для отримання облікових записів із підвищеними привілеями було застосовано атаку Kerberoasting.
(('AD_Computers: {0}' -f ([adsiSearcher]'(ObjectClass=computer)').FindAll().count)
([adsisearcher]'(&(objectCategory=user)(servicePrincipalName=*))').FindAll()
Зловмисник переважно використовував протокол віддаленого робочого столу (RDP) та кілька скомпрометованих облікових записів для переміщення між системами в мережі жертви. Подальший аналіз показав, що для віддаленого доступу також застосовувалися інструменти AnyDesk і, ймовірно, LogMeIn.
Крім того, на скомпрометованих машинах було зафіксовано встановлення PuTTY, який, імовірно, використовувався для бічного переміщення до Linux-хостів. Точний спосіб доставки та запуску цих інструментів на заражених системах наразі встановити не вдалося.
Нижче наведено приклади виконання RDP-команд, зафіксовані під час аналізу, з прихованими IP-адресами.
mstsc /v 10.*.*.* .\conhost.exe -d \10.*.*.*\e$
Під час атаки зловмисник запускав на комп’ютері жертви інструменти storage-explorer та AzCopy, які зазвичай використовуються для роботи зі сховищами Azure. Перший із них дозволяє переглядати вміст сховищ і керувати даними, а другий призначений для копіювання файлів до віддаленого Azure-сховища.
На основі аналізу мережевих слідів можна зробити висновок, що storage-explorer використовувався для пошуку й відбору чутливої інформації в мережі жертви. Після цього зібрані дані передавалися за допомогою AzCopy до Azure Blob-сховища, яке перебувало під контролем зловмисника.
Яким саме чином storage-explorer та AzCopy потрапили на систему жертви, встановити не вдалося.
На фінальному етапі зловмисник розгорнув шифрувальник ransomware Interlock під назвою conhost.exe, маскуючи його під легітимний системний файл. Бінарний файл зберігався у тимчасовій папці даних застосунків користувача в директорії з назвою, що складалася з однієї цифри, наприклад 3 або 4.
Після запуску шифрувальник зашифровував цільові файли на комп’ютері жертви, додаючи до них розширення .Interlock. У кожній папці, де відбувалася спроба шифрування, створювався файл із запискою про викуп !README!.txt.
Також було зафіксовано, що зловмисник налаштував показ записки з вимогою викупу під час інтерактивного входу користувача в систему. Це було реалізовано через Group Policy Objects (GPO), стандартний механізм Windows для централізованого керування системами та застосунками.
У самій записці зловмисник застерігає від будь-яких спроб відновлення зашифрованих файлів і від перезавантаження уражених машин. Жертві висувається вимога надати відповідь протягом 96 годин. У разі ігнорування погрозливо заявляється про публікацію викрадених даних на сайті витоків і інформування медіа, що може призвести до серйозних фінансових та репутаційних втрат.
У записці з вимогою викупу міститься URL-адреса onion-сайту, через який постраждалі організації можуть зв’язатися з оператором для обговорення умов викупу та придбання ключів дешифрування. Для кожної жертви генерується унікальний ідентифікатор компанії, що складається з шістдесяти буквено-цифрових символів.
Було зафіксовано, що ransomware Interlock має варіанти як для Windows у форматі Portable Executable (EXE), так і для Linux у форматі ELF. Це свідчить про те, що зловмисник орієнтується одночасно на Windows- і Linux-системи.
Бінарний файл шифрувальника Interlock є 64-бітним виконуваним файлом, скомпільованим 2 жовтня 2024 року. На системах жертв ransomware з’являється у запакованому вигляді. Власний код розпакування розміщений у Thread Local Storage, а також у бінарному файлі присутні обфусковані рядки стеку, які розшифровуються під час виконання шкідливого коду.
Після запуску на системі жертви ransomware ініціалізує свою роботу, завантажуючи власні структури, рядки та функції API. Після цього починається перелік доступних логічних дисків. Спочатку перевіряються літери дисків від A до Z, при цьому диск C на цьому етапі виключається.
Далі шифрувальник обирає доступні логічні диски, перебирає всі папки та файли на них і шифрує цільові дані, додаючи до зашифрованих файлів розширення .interlock. Після завершення обробки логічних дисків ransomware переходить до переліку та шифрування файлів на диску C.
Під час цього процесу ransomware навмисно пропускає певні папки та типи файлів, які не підлягають шифруванню. Список винятків для папок і розширень файлів жорстко прописаний безпосередньо в бінарному файлі Interlock.
Список виключених папок для Windows-варіанту Interlock:
Список виключених розширень файлів для Windows-варіанту Interlock:
Linux-варіант ransomware Interlock виконує схожий процес переліку директорій і файлів, починаючи з кореневої директорії. Під час цього процесу шифруються всі цільові файли, за винятком тих, чиї розширення входять до списку виключень, жорстко закодованого безпосередньо в бінарному файлі.
Список виключених розширень файлів для Linux-варіанту Interlock:
Ransomware Interlock використовує криптографічну бібліотеку LibTomCrypt. Це відкрита, модульна та портативна бібліотека, призначена для реалізації різних алгоритмів шифрування.
Windows-варіант Interlock застосовує метод шифрування Cipher Block Chaining (CBC) для шифрування файлів на комп’ютері жертви. Водночас Linux-варіант Interlock використовує або CBC, або RSA як метод шифрування залежно від конкретної реалізації.
Після шифрування кожного з цільових файлів на комп’ютері жертви Interlock створює файл із запискою про викуп !README!.txt у кожній з папок, які були оброблені під час переліку директорій.
Було зафіксовано, що Windows-варіант Interlock створює заплановане завдання Windows з назвою TaskSystem, яке щоденно о 20:00 запускається на системі жертви від імені користувача SYSTEM. Це завдання виконує налаштовану команду для запуску ransomware, що свідчить про налаштування механізму постійної присутності.
Крім того, ransomware має можливість самостійно видаляти себе після завершення шифрування цільових файлів, приховуючи сліди наявності шифрувальника на комп’ютері жертви.
Для видалення бінарного файлу шифрувальника у Windows-варіанті Interlock використовується невеликий DLL-модуль, вбудований у секцію даних. Цей DLL-файл вивантажується у тимчасову папку застосунків користувацького профілю під назвою tmp41.wasd.
Після цього для запуску експортованої функції DLL з назвою run використовується rundll32.exe. Ця функція, своєю чергою, викликає remove(), яка видаляє бінарний файл шифрувальника.
Linux-варіант використовує схожий підхід для видалення бінарного файлу шифрувальника з системи жертви. Для цього виконується функція removeme, яка є вбудованою процедурою безпосередньо в тому самому бінарному файлі шифрувальника.
Існує припущення з низьким рівнем упевненості, що ransomware Interlock є новою диверсифікованою групою, яка могла сформуватися на основі операторів або розробників Rhysida. На це вказує низка схожостей у тактиках, техніках і процедурах, використовуваних інструментах, а також у поведінці самих бінарних файлів шифрувальників.
Під час аналізу було виявлено перетин коду в бінарних файлах Interlock і Rhysida. Зокрема, список виключень для файлів і папок, жорстко прописаний у Windows-варіанті Interlock, має помітну схожість зі списком виключень, який раніше використовувався в Rhysida.
Крім того, шифрувальник Interlock із назвою файлу conhost.exe раніше вже фіксувався під час атак Rhysida. Також простежуються спільні елементи в TTP та наборі інструментів, серед яких PowerShell-скрипти, AnyDesk і PuTTY.
Обидві групи використовують AzCopy для ексфільтрації даних жертви до Azure Blob-сховища, що перебуває під контролем зловмисника. Це техніка не нова, але використовується доволі рідко, що додатково підсилює зв’язок між цими кампаніями.
Окремо варто відзначити схожість у стилі записок з вимогою викупу. І Interlock, і Rhysida подають себе як умовного «партнера», який повідомляє жертву про злам і нібито пропонує допомогу у виправленні ситуації. Такий підхід контрастує з риторикою інших відомих і агресивних угруповань, наприклад Black Basta та ALPHV, чиї записки зазвичай побудовані на прямих погрозах, тиску та спробах залякування.
Можлива пов’язаність Interlock з операторами або розробниками Rhysida добре вписується в ширші тенденції сучасного кіберзагрозового ландшафту. Останніми роками дедалі частіше спостерігається, що ransomware-групи розширюють свої можливості, переходячи до складніших і більш різнопланових операцій.
Крім того, такі угруповання стають менш ізольованими. Все частіше одні й ті самі оператори співпрацюють одразу з кількома ransomware-групами, обмінюються інструментами, інфраструктурою та тактиками. Це розмиває чіткі межі між окремими угрупованнями і ускладнює атрибуцію конкретних атак.
Interlock показує, наскільки зрілими стали сучасні ransomware-атаки. Це вже не швидке шифрування заради викупу, а довга і продумана операція з розвідкою, викраденням даних, бічним переміщенням і тиском на жертву. Схожість з Rhysida і використання перевірених інструментів лише підкреслюють загальну тенденцію. Межі між окремими угрупованнями стираються, а ransomware дедалі більше перетворюється на гнучку сервісну модель з чіткою орієнтацією на масштаб і прибуток.
