LokiBot після десятиліття: Аналіз недавньої кампанії
Detection stack
- AIDR
- Alert
- ETL
- Query
Резюме
LokiBot — це тривалий стілер інформації, призначений для збору облікових даних з браузерів, криптовалютних гаманців та інших конфіденційних додатків. Остання кампанія спирається на багатоступеневий ланцюжок виконання, який починається з обфускованого вкладення JScript, надісланого через шкідливий спам. Шкідливий код використовує ін’єкцію процесів і хешування API для зменшення видимості, відправляючи вкрадені дані до своєї командно-контрольної інфраструктури.
Розслідування
Розслідування вивчило багатоступеневий зразок LokiBot і прослідкувало його розвиток від вкладення JScript до завантажувача PowerShell, потім до ін’єктора .NET, і нарешті до корисного навантаження LokiBot. Аналітики виявили використання захисту ConfuserEx, дешифрування на основі XOR та техніки віддзеркалювального завантаження на всьому ланцюгу. У дослідженні також описано користувальницький підхід до хешування API і хибний метод стійкості, заснований на реєстрі.
Зменшення загрози
Організаціям слід розгорнути сильний фільтр електронної пошти для блокування зловмисних вкладень JScript та шкідливого спаму до доставки. Моніторинг підозрілих дочірніх процесів, створених wscript.exe and powershell.exe також є важливим. Крім того, обмеження виконання ненадійних .NET збірок та стеження за незвичними змінами в ключах запуску Windows може допомогти зменшити ризик.
Реакція
Якщо виявлено LokiBot, негайно ізолюйте уражену кінцеву точку, щоб запобігти подальшому викраденню даних та спілкуванню командно-контрольних команд. Слідчі повинні провести судову експертизу для визначення початкової точки входу та оцінки масштабу компрометації облікових даних. Усі облікові записи, до яких було доступ з інфікованого хоста, повинні пройти повне скидання пароля, і середовище повинно бути скановане на виявлення пов’язаних JScript та PowerShell артефактів.
Потік атаки
Виявлення
Можливі точки стійкості [ASEPs – Software/NTUSER Hive] (через події реєстру)
Переглянути
Можливість виконання через приховані командні рядки PowerShell (через cmdline)
Переглянути
LOLBAS WScript / CScript (через створення процесу)
Переглянути
Підозрілі рядки Powershell (через powershell)
Переглянути
Зв’язок LokiBot C2 через HTTP-запит [Windows Network Connection]
Переглянути
Виявлення ін’єкції процесу LokiBot через aspnet_compiler.exe [Створення процесу в Windows]
Переглянути
Виявлення виконання LokiBot через Base64 скрипт PowerShell та завантаження зібрання .NET [Windows Powershell]
Переглянути
Виконання симуляції
Передумова: Повинна пройти перевірка телеметрії та базової лінії перед початком.
Обгрунтування: Цей розділ детально описує точне виконання техніки противника (TTP), розробленої для того, щоб викликати правило виявлення. Команди та наратив ПОВИННІ безпосередньо відображати визначені TTP і ціль – згенерувати точну телеметрію, очікувану за логікою виявлення. Абстрактні або не пов’язані приклади призведуть до неправильної діагностики.
-
Опис атаки та команди: Противник успішно отримав початковий доступ через файл JScript. Щоб уникнути збереження виявленого
.dllфайл на диск, вони виконують команду PowerShell, що містить закодований у Base64 рядок. Цей скрипт, коли розшифрований, використовує можливості.NET Reflectionдля виклику[System.Reflection.Assembly]::Loadщоб завантажити шкідливе навантаження безпосередньо в пам’ять поточного процесу. Такий “безфайловий” підхід є характерною ознакою LokiBot. -
Скрипт регресійного тесту:
# Скрипт симуляції LokiBot # Цей скрипт розроблений для відповідності точним рядкам, визначеним у правилі виявлення. # 1. Симуляційний компонент Base64 $encodedCommand = "Base64-encoded PowerShell script" $dummyPayload = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes("DummyPayload")) # 2. Симуляційний компонент завантаження зібрання з використанням точного рядка з правила виявлення # Використовуємо try/catch, оскільки це симуляція, і "навантаження" не є справжнім зібранням. try { Write-Host "Виконання закодованої стадії..." Write-Output $encodedCommand # Цей рядок є основним тригером для правила виявлення $trigger = "[System.Reflection.Assembly]::Load" Write-Host "Спроба завантажити зібрання через: $trigger" # Викликаємо через Invoke-Expression, щоб забезпечити відображення в ScriptBlockText Invoke-Expression "Write-Host 'Тригер: $trigger'" } catch { Write-Error "Симуляція не змогла виконати рядок тригера." } -
Команди очищення:
# Симуляційний скрипт не виконує постійних змін. # Просто очищаємо консоль і забезпечуємо відсутність залишкових процесів. Clear-Host Write-Host "Очищення симуляції завершено. Файли не зберігалися."