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

Инструмент группировки 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