Через блокчейн к данным ⭐️

Исследователи из Socket и Checkmarx рассказали об интересной вредоносной кампании в NPM. Злоумышленники мимикрировали под плагины для Puppeteer и блокчейн-клиенты. Для получения IP-адреса актуального командного сервера используется смарт-контракт в блокчейне Ethereum 😦

Из занятного — в коде библиотек используется несколько комментариев на русском:

• console.error("Ошибка при получении IP адреса:", err);
• console.error("Ошибка при запуске файла:", _0x88fda8);
• console.error("Ошибка установки:", _0x14ce94);

Socket предлагает быть осторожным с атрибуцией, так как это может быть следствием переиспользования кода либо сделано нарочно.

В зависимости от вашей платформы будет скачан и запущен один из следующих исполняемых файлов: node-win.exe, node-linux, node-macos. Ниже мы будем называть их агентами.

Мы изучили кампанию подробнее и обнаружили еще несколько интересных деталей.

1️⃣ Несмотря на то что Socket и Checkmarx приводят только один IP-адрес в качестве сетевого IoC, функция назначения нового URL в смарт-контракте вызывалась несколько раз. Всего нам известно о пяти адресах, и самым ранним из них был http://localhost:3001 😈, остальные представляют собой VPS-серверы.

2️⃣ Агент умеет закрепляться в системе и так же, как и JS-библиотеки, скачивающие и запускающие его, получать C2 через блокчейн. Исполняемый файл представляет собой Node.js Single Executable Application, который упаковывает проект и интерпретатор JS в единый файл.

3️⃣ Агент периодически опрашивает сервер на предмет команд в виде JS-кода. Первая нагрузка собирает информацию о системе жертвы: модель процессора, количество ядер, объем оперативной памяти, данные о видеокарте. Полученная информация отправляется обратно на сервер.

4️⃣ Агенты получают просто true, если нет новых задач. Из интересного: корень HTTP-сервера возвращал следующую ошибку:

{"statusCode":404,"message":"ENOENT: no such file or directory, stat '/root/botnet-server/public/index.html'"}

Эта строка проливает свет на возможные цели злоумышленника ☕️

IoCs:

http://194.53.54.188:3001
http://193.233.201.21:3001
http://45.125.67.172:1337
http://45.125.67.172:1228
194.53.54.188
193.233.201.21
45.125.67.172

#ti #npm #pyanalysis #scs
@ptescalator

Да что не так с этим AES? ❔

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

На примере одного из семейств ВПО, замеченного в атаках на Латинскую Америку, разберем случай, в котором применяется продвинутая техника шифрования, но прячется она внутри самой, казалось бы, классической.

👾 Grandoreiro — бразильский банковский троян, который активен с 2016 года по сегодняшний день. Он доставляется в систему с помощью загрузчика, который получает ссылку на скачивание полезной нагрузки от С2-сервера.

Предыдущие схемы дешифрования строк в Grandoreiro (в частности, в загрузчике) включали кастомное декодирование зашифрованных строк, ключа AES и IV путем простой замены. Эти компоненты дешифровались с помощью XOR, и далее шифротекст расшифровывался окончательно с помощью ключа AES и IV в режиме AES CBC 256 бит.

🧐 При анализе недавних образцов Grandoreiro была замечена новая для этого семейства техника шифрования, которая применяется для усложнения анализа, — Ciphertext Stealing (CTS). Это режим шифрования, который используется, когда открытый текст не кратен размеру блока.

Например, одна из наиболее известных схем паддинга (PKCS #7) дополняет последний блок байтами, чтобы гарантировать, что он по размеру совпадает с полным блоком. CTS работает без паддинга. Его работу мы заметим над последним неполным блоком данных (который не кратен размеру блока).

Что именно происходит:

1️⃣ Шифруется последний полный блок.

2️⃣ Зашифрованный последний полный блок «ксорится» с частичным (неполным) блоком.

Такой способ предоставляет возможность шифровать открытый текст произвольной длины без добавления паддинга, сохраняя исходный размер данных.

Чтобы на практике понять, как это работает, посмотрим на реализацию алгоритма:

cipher = AES.new(aes_key, AES.MODE_ECB)
    encr = b"\x00"*16
    initial_key = cipher.encrypt(encr) # your value here
 
    block_size = 16
    total_blocks = len(ciphered_data) // block_size
    decrypted_data = bytearray()
    previous_block = initial_key
 
    if total_blocks:
        # Decrypt all complete blocks
        for i in range(total_blocks):
            current_block = ciphered_data[i * block_size:(i + 1) * block_size]
            key = previous_block
            decr_block = cipher.decrypt(current_block)
            decrypted_data.extend(bytes(x ^ y for x, y in zip(decr_block, key)))
            previous_block = current_block
 
        # Handle the last block with ciphertext stealing
    if len(ciphered_data) % block_size > 0:
        last_full_block = previous_block
        if total_blocks:
            last_full_block = cipher.encrypt(last_full_block)[:len(ciphered_data) - (i + 1) * block_size] #take as much bytes off of the last full block (encrypted) as remained yet to decrypt (ciphertext)
            partial_block = ciphered_data[(i + 1) * block_size:len(ciphered_data)] #bytes left to decrypt, not a multiple of the block size
        else:
            last_full_block = cipher.encrypt(last_full_block)[:len(ciphered_data)]
            partial_block = ciphered_data[:len(ciphered_data)]
         
        stolen_block = bytes(x ^ y for x, y in zip(partial_block, last_full_block))
        decrypted_data.extend(stolen_block)

Метод довольно оригинальный, и в Grandoreiro он прячется внутри функций, которые реализуют обычный, на первый взгляд, AES.

Поэтому, прежде чем начинать писать скрипты расшифровки, видя заветную аббревиатуру, следует посмотреть на код внимательно — убедиться, что используется действительно классическая версия алгоритма, и не тратить часы в поиске ответа на вопрос «ну почему оно не расшифровывается?».

#TI #tip #malware
@ptescalator

📑 TaxOff: кажется, у вас… бэкдор

В третьем квартале специалисты TI-департамента экспертного центра безопасности Positive Technologies (PT Expert Security Center, PT ESC) обнаружили серию атак, направленных на государственные структуры России. Связей с уже известными группами, использующими такие же техники, нам установить не удалось.

😐 Основными целями киберпреступников были шпионаж и закрепление в системе для развития последующих атак. Эту группировку мы назвали TaxOff из-за использования писем на правовые и финансовые темы в качестве приманок. В своих атаках злоумышленники применяли написанный минимум на C++17 бэкдор, который мы назвали Trinper из-за артефакта, используемого при соединении с C2-сервером.

📩 Начальный вектор заражения — фишинговые письма. Мы обнаружили несколько таких: в одном была ссылка на Яндекс Диск с вредоносным содержимым, связанным с «1С», в другом — фальшивый установщик ПО для заполнения справок о доходах и расходах, которые госслужащим необходимо подавать каждый год. И ежегодно это ПО обновляется и становится целью злоумышленников, распространяющих вредоносы под видом обновлений.

Trinper — написанный на C++ многопоточный бэкдор с гибкой конфигурацией, в котором используются шаблонный метод в качестве паттерна проектирования, контейнеры STL, буферный кэш для повышения производительности.

🧐 Подробный анализ бэкдора и действий группировки TaxOff, а также индикаторы компрометации вы можете найти в отчете.

#TI #APT #IOC #Reverse
@ptescalator

Нас — много. И еще годных каналов немало! 😃

Мы собрали в одной папке паблики знакомых коллег по цеху — рекомендуем к изучению.

Опрос — на следующей неделе 😏

@ptescalator

Mount Point — pt.1 🙂

Любое расследование — это анализ артефактов операционной системы. А чтобы их получить, зачастую приходится работать с образами виртуальных машин, типа VMDK, VDI, qcow и других.

В большинстве случаев монтирование, а потом и исследование подобных данных не представляет сложностей. Но если образ по каким-то причинам не обрабатывается популярными утилитами (FTK Imager, Arsenal Image Mounter), имеет особенности конфигурации или если вам необходимо провести какие-либо специфические процедуры, монтирование образа в виртуальную среду может оказаться непростым.

В этом и нескольких будущих постах мы дадим небольшие гайды по разрешению типовых ситуаций. Stay connected!

Case 1. Монтирование отдельных разделов из образа (все действия легко осуществимы в любом стандартном дистрибутиве ОС Linux и подсистеме WSL, если каких-то пакетов на системе нет, они без проблем устанавливаются стандартными средствами).

🐾 Шаг 1. Преобразуем имеющийся образ в формат RAW. Это наиболее универсальный формат, не содержащий никаких дополнительных данных, не имеющий сжатий и максимально поддерживаемый любыми утилитами. Образ может представлять собой один файл или несколько (например, если разные каталоги Linux разнесены на несколько виртуальных дисков). Рекомендуем использовать утилиту qemu-img:

qemu-img convert -f #Исходный формат -O #Целевой формат #Файл-источник #Файл-получатель

Это наиболее универсальный способ, поддерживающий большинство форматов виртуальных дисков (VMDK, VDI, qcow и другие), а также позволяющий собрать образ из нескольких файлов. Кроме того, можно использовать вендорские утилиты, входящие в стандартные дистрибутивы, например:

VirtualBox: VBoxManage.exe internalcommands converttoraw

VMware: vmware-vdiskmanager -r ./source-image.vmdk -t 2 ./destination-image.raw

🐾 Шаг 2. Изучаем параметры полученного образа:

fdisk -l ./#путь к файлу

И видим подобную запись:

Sector size (logical/physical): 512 bytes / 512 bytes
    
./vm-disk-0.raw1 : start=        2048, size=   207618048, type=83
./vm-disk-0.raw2 : start=   207620096, size=     2095104, type=82

По идентификатору раздела (их можно посмотреть здесь) определяем нужный (в примере — Type 83 Linux Partition) и считаем параметры смещения и размер диска:

512 (размер сектора) × 2048 (номер первого сектора) = 1 048 576 (смещение в байтах)

512 (размер сектора) × 207 618 048 (количество секторов) = 106 300 440 576 (размер раздела в байтах)

🐾 Шаг 3. Монтируем:

mount -o ro,loop,offset=1048576,sizelimit=106300440576 source /mountpoint

💡 Полезные заметки:

1. Для команды mount используйте опцию ro (read-only), чтобы случайно ничего не изменить в исследуемом образе.

2. При работе с образами Windows используйте опцию show_sys_files для отображения скрытых системных файлов ($MFT, $LogFile, $J и т. п.) и streams_interface=windows — для поддержки работы с альтернативными потоками.

Все! В каталоге точки монтирования видим содержимое интересующего нас раздела.

В следующем посте рассмотрим монтирование LVM-дисков и поделимся полезным скриптом. Stay tuned!

#tip #dfir
@ptescalator