Инструмент группировки APT31. CloudyLoader 🌩

В одном из инцидентов команде PT ESC IR попался интересный вредоносный файл, который загружает полезную нагрузку в несколько этапов. Вредоносный образец состоит из легитимного файла компонента BsSndRpt.exe программного обеспечения BugSplat, которое представляет собой систему сбора и анализа отчетов об ошибках, динамической библиотеки BugSplatRc64.dll и файла полезной нагрузки (шелл-кода). Для правильной работы легитимного файла необходима BugSplatRc64.dll, которая является загрузчиком.

Вредоносная динамическая библиотека накрыта протектором VmProtect версии 3, имя секции изменено на .qwdlgje (скриншот 1). Для сокрытия вызовов Windows API вредонос использует технику API Hashing: для поиска имени функции и имени DLL вычисляется хеш. Алгоритм хеширования следующий:

def CalculateAPIHash(data: bytes):
    v3 = 0xFFFFFFFF
    for byte in data:
        temp1 = (2 * byte) ^ ((2 * byte) ^ (byte >> 1)) & 0x55555555
        v4 = temp1 >> 2
        v5 = 4 * temp1
        temp2 = v5 ^ (v5 ^ v4) & 0x33333333
        v6 = ((temp2 >> 4) | (16 * (temp2 & 0xFF0F0F0F))) & 0xFFFFFFFF
        v8 = int.from_bytes(v6.to_bytes(4, 'little'), 'big')
        for _ in range(8):
            if (v3 ^ v8) & 0x80000000:
                v3 ^= 0xC520DEC7
            v3 = (v3 * 2) & 0xFFFFFFFF
            v8 = (v8 * 2) & 0xFFFFFFFF
    
    v9 = (~v3) & 0xFFFFFFFF
    v10 = (4 * ((2 * v9) ^ ((2 * v9) ^ (v9 >> 1)) & 0x55555555))  & 0xFFFFFFFF
    v11 = (v10 ^ (v10 ^ (((2 * v9) ^ ((2 * v9) ^ (v9 >> 1)) & 0x55555555) >> 2)) & 0x33333333)  & 0xffffffff
    v11 = ((16 * v11) ^ ((16 * v11) ^ (v11 >> 4)) & 0xF0F0F0F) & 0xffffffff
    return int.from_bytes(v11.to_bytes(4, 'little'), 'big')

При вычислении хеш-значения имена DLL должны подаваться на вход уже в верхнем регистре (например, KERNEL32.DLL), в то время как имена функций остаются без изменения.

После всех подготовок BugSplatRc64.dll создает процесс makecab.exe, операцией XOR с ключом 5d 72 89 80 расшифровывается файл полезной нагрузки, которая представляет собой шелл-код. Все строки, используемые в DLL, зашифрованы XOR.

Этапы получения основной нагрузки

1. Запрос к репозиторию scrcpyClone пользователя Range1992: https://raw.githubusercontent.com/Range1992/scrcpyClone/refs/heads/master/app/data/zsh-completion/_scrcpy (скриншоты 2, 3). В полученных из Git данных вредоносный код ищет маркер начала (QQNSR4u) и конца (ZsNpk7Y) закодированной строки. Далее получает данные между маркерами, декодирует из формата Base64, расшифровывает с помощью алгоритма RC4 с ключом 03 07 A0 B0 E3 80 88 77. Полученные данные — адрес основной нагрузки.

2. Запрос к адресу: https://github.com/Range1992/scrcpyClone/raw/refs/heads/master/app/deps/PersonalizationCSP. Зашифрованная основная нагрузка содержит следующие данные:

• ключ RC4 — 8 байт;
• длина полезных данных — 4 байта;
• полезные данные.

Основная полезная нагрузка представляет собой шелл-код CobaltStrike со следующей конфигурацией:

BeaconType                  - HTTPS
Port                        - 443
SleepTime                   - 77665
MaxGetSize                  - 409721416
Jitter                      - 46
PublicKey_MD5               - fe7aa97fbe3fe21e59ead1792ca2dc58
C2Server                    - Moeodincovo.com,/divide/mail/SUVVJRQO8QRC,www.Moeodincovo.com,/divide/mail/SUVVJRQO8QRC
UserAgent                   - Mozilla/5.0 (Windows NT 6.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0
HttpPostUri                 - /Terminate/v6.49/LTKAZNE9

Признаками присутствия этого ВПО может служить наличие в файловой системе неподписанной DLL-библиотеки с именем BugSplatRc64.dll.

IoCs:

https://raw.githubusercontent.com/Range1992/scrcpyClone/refs/heads/master/app/data/zsh-completion/_scrcpy
https://github.com/Range1992/scrcpyClone/raw/refs/heads/master/app/deps/PersonalizationCSP
https://Moeodincovo.com/divide/mail/SUVVJRQO8QRC
3356a7d25096e24afe3409540a06f42b2b5012e55a8cad3f6ee06ec13e3471a5
879949e6d70f2d7e21c489552240b13f927fa9586ef7a9343fa07741248860f3

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

Как создать правила для сетевого трафика под будущую угрозу 🤨

Об этом на этой неделе в Китае во время третьего саммита по кибербезопасности, в рамках которого прошла шестая международная антивирусная конференция, рассказала Ксения Наумова, старший специалист отдела сетевой экспертизы антивирусной лаборатории PT ESC. В канале делимся подробностями из доклада 🍸

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

Экзактовые сигнатуры обладают одним несомненным преимуществом — они ловят ровно те вредоносные образцы, на которые были написаны, но это же является их главной слабостью: при даже небольшом изменении какого-либо компонента сетевого взаимодействия правила перестают срабатывать.

Мы решили, что этот недуг можно смело обернуть в преимущество: сигнатуры могут ловить не только экзактовые вредоносы, но и аномальное поведение, которое эти образцы порождают.

Что может являться интересующей нас аномалией?

➡️ Необычные размеры пакетов;
➡️ неизвестные протоколы;
➡️ подозрительные DNS-запросы / подозрительные TLD в DNS;
➡️ скачки трафика / задержки;
➡️ нарушения RFC;
➡️ применение обфускации, кодирования, шифрования;
➡️ и многое другое…

Мы провели небольшой анализ существующих правил на детектирование аномалий в наборе опенсорсных сигнатур Emerging Threats — HUNTING (скриншот 1):

➡️ ~510 правил на XOR-шифрование HTTP-запросов;
➡️ ~50 правил на кодированные в Base64 данные;
➡️ ~50 правил на подозрительные TLD в DNS;
➡️ правила на содержимое в ZIP, эксфильтрацию и т. п.

Показательный пример удачного hunting-правила:

alert http $HOME_NET any -> $EXTERNAL_NET any (sid: 2027117; msg:"ET HUNTING Suspicious POST with Common Windows Process Names - Possible Process List Exfiltration"; flow:established,to_server; http.method; content:"POST"; http.request_body; content:"csrss.exe"; content:"explorer.exe"; fast_pattern; content:"svchost.exe"; content:"lsass.exe"; ...)

А на скриншоте 2 — пример такого подозрительного трафика.

Однако искать аномалии можно не только с помощью открытых правил, но и самостоятельно — например, нарушения RFC, конкретно RFC 2616, определяющего протокол HTTP (скриншот 3). Можно поискать HTTP-запросы, у которых заголовок Referer не содержит схему:

alert http any any -> any any (msg: "SUSPICIOUS [PTsecurity] HTTP header Referer RFC2616 violation"; flow: established, to_server; content: "Referer|3a|"; http_header; content: !"Referer|3a 20|http"; http_header; ...)

В наши сети попадал бэкдор EAGERBEE и другие интересные образцы (скриншот 4).

Или, например, можно поискать простую команду PING внутри GZIP (скриншот 5):

alert tcp any any -> any any (msg: "SUSPICIOUS [PTsecurity] Generic Ping command inside Gzip"; flow: established, to_server; content: "|1f 8b 08 00 00 00 00 00 04 00 0b c8 cc 4b 07 00 c3 92 e7 85 04 00 00 00|"; ...)

По итогам срабатываний и дальнейших исследований к нам попадали SheetRAT и zgRAT (скриншот 6).

Но основная мысль, зафиксированная в докладе, — в использовании корреляции их сработок. Корреляция сработок — понятие не новое, но в контексте сетевого трафика его пока применяют крайне редко; иногда уходят в более сложные реализации защиты и забывают о простых, но действенных подходах.

🫵 Выводы простые: generic-правила, особенно в корреляции друг с другом, могут значительно помогать в детектировании как давно известных, так и абсолютно новых угроз, о которых пока никто не знает. Можно пользоваться открытыми наборами сетевых сигнатур — ET Open, PT Open, а можно смело писать свои.

Happy hunting!

#suricata #network #signature #rules #hunt #detect
@ptescalator