Злоумышленники не стесняются использовать Python для своих целей. LazyStealer, упакованная PyInstaller, Python-бэкдор в ShadowPad и модули для Pupy RAT тому доказательство. Кроме того, задачи на снятие пакеров с дальнейшим исследованием встречаются на соревнованиях capture the flag.

Команда Supply Chain Security собрала памятку по работе с инструментами PyInstaller, py2exe и со скомпилированными файлами .pyc.

PyInstaller

Один из самых популярных инструментов для упаковывания проекта в исполняемый файл под Windows, Linux, macOS. Библиотеки, относящиеся к проекту, дополнительно сериализуются с помощью стандартной библиотеки marshal в PYZ-файл.

Для работы с PyInataller можно использовать один из первых проектов — pyinstxtractor. Marshal не реализует обратную совместимость между своими версиями, поэтому для распаковки PYZ-файла pyinstxtractor требует запуска на той версии Python, которой был упакован PyInstaller.

Решает этот нюанс pyinstxtractor-ng: он использует библиотеку xdis, реализующую (де)сериализатор под Python 2.4–3.13, в силу чего для полной распаковки больше не требуется конкретная версия Python. Автор pyinstxtractor-ng выпустил веб-версию, переписанную на Go, она работает локально в браузере. Оба проекта активно обновляются и разбирают последние версии PyInstalller.

py2exe

Решение, нацеленное на упаковку проекта в исполняемый файл под Windows. Чуть-чуть не успевает за тенденциями и пока не умеет работать с Python 3.12 и 3.13. «Убийцей» пакера должен был стать unpy2exe, но последний коммит в master семь лет назад оставляет чувство печали. Автор этого решения так же, как и автор решения pyinstxtractor, предупреждает, что версии (хотя бы major) установленного Python и конечной нагрузки должны совпадать.

Файлы .pyc

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

1️⃣ Uncompyle6 и decompyle3 — две утилиты от автора вышеупомянутого xdis. Uncompyle6 покрывает версии Python до 3.8, decompyle3 — c 3.7 до, частично, 3.9. Автор просит помочь с проектом.

2️⃣ Семейство unpyc (unpyc3, unpyc37, unpyc37-3.10) — поддерживает точечно версии 3.3, 3.7, 3.10.

3️⃣ Pycdc — многообещающий декомпилятор, написанный на C++, также регулярно обновляется и старается поддерживать все версии байт-кода Python. Порой имеет сложности с разбором конструкций, поэтому…

4️⃣ Pycdas — дизассемблер из проекта pycdc, помогает попробовать разобрать файл с расширением .pyc, когда декомпиляторы уже бессильны 🐱🐱🐱

Существующие онлайн-проекты для файлов .pyc (осторожно, отправляют файлы на сервер):

• Decompiler.com — мультифункциональный, «под капотом» uncompyle6.

• PyLingual.io — многообещающее решение, находящееся в бете. Файлы версий 3.11, 3.12, 3.13 открывает без проблем.

Happy hacking!

#ti #python #tools #scs
@ptescalator

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

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

К сожалению, такие распространенные инструменты, как средства просмотра строк (например, strings или FLOSS), а также анализаторы PE-файлов (например, Detect It Easy или CFF Explorer) отображают только самый низкий уровень детализации и не предлагают пользователям помощи в интерпретации полученных данных.

😠 Для решения задачи оперативного анализа кода и поиска реализованных в программе вредоносных техник можно применить сканирование с помощью эвристических движков. Эти движки используют набор правил, которые направлены на выявление специфических участков кода или отдельных артефактов, характерных для определенных техник. Хорошим примером такого движка является capa от Mandiant.

Проанализировав интересующий вас файл с помощью этого инструмента, вы можете получить перечень задетектированных техник, как например на скриншотах 1 и 2.

☹️ Как работать с этими данными? Чтобы выявить ВПО, можно поступить следующим образом:

1️⃣ Проанализировать все имеющиеся правила capa.

2️⃣ Выставить для каждого из них рейтинг опасности (например, в виде числа от 0 до 10).

3️⃣ Задать пороговое значение для классификации файла как вредоносного.

4️⃣ Суммировать рейтинги детектов анализируемого файла и сравнить их с пороговым значением: если сумма рейтингов больше, значит файл потенциально вредоносный.

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

🫰 Но можно копнуть глубже и использовать capa как вспомогательный инструмент для реверса. Тут нам поможет тот факт, что детекты capa позволяют локализовать место в коде файла, где была реализована та или иная техника (скриншот 3).

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

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

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

#tip #tool #malware
@ptesaclator

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

✍️ VHDX-файл — это виртуальный диск, который можно подключить к системе начиная с Windows 8 двойным нажатием мыши. Он будет считаться логическим томом до выключения системы.

Как и любой контейнер, VHDX-файл может выступать в роли вредоносного объекта. Исследователь Уилл Дорманн в посте от 2019 года рассказал, что с помощью специально подготовленного образа можно спровоцировать системную ошибку в Windows и вызвать «синий экран смерти».

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

💡 Для хакеров преимущество в использовании VHDX-файлов (как и в использовании ZIP-файлов) заключается в том, что они не подпадают под действие MoTW (Mark of the Web): при запуске документа из этих контейнеров не включается режим Protected View, а Windows SmartScreen не предупреждает жертву об опасности. Стоит также отметить, что под VHDX-формат приспособлено меньшее количество антивирусных решений, чем под те же ISO-файлы. Следовательно, при попадании в систему образ вряд ли будет моментально удален этим СЗИ.

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

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

👀 Рассмотрим наиболее эффективные методы и инструменты, которые можно использовать для анализа диска:

• Создание виртуальной машины и монтирование диска в нее. Это позволит посмотреть файлы в проводнике и увидеть то, что получила жертва атаки (но не удаленные файлы).

• Autopsy — универсальный инструмент для исследования образов, который может получать данные из множества файлов разных типов, физических дисков, сырых образов. Есть таймлайн изменения файлов внутри образа (пример — на втором скриншоте).

• FTK Imager — аналог программы Autopsy, показавший наилучшие результаты в извлечении удаленных файлов с диска.

🛡 Как вариант защиты от атак с использованием VHDX стоит использовать почтовые фильтры, запрещающие передачу этого типа файла во вложениях писем — как от внешних отправителей, так и от внутренних.

В скором времени мы опубликуем статью, в которой детально разберем эту атаку. Следите за новостями.

#ti #tool #tip #news
@ptescalator

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

Чтобы этого избежать, можно воспользоваться первоначальной фильтрацией входного потока событий безопасности, позволяющей устранить ложноположительные срабатывания с помощью белых списков индикаторов. Для этого отлично подойдет открытый репозиторий MISP Warning Lists. Сейчас в нем содержится 89 различных наборов индикаторов, распределенных по группам.

Все наборы индикаторов в этом источнике можно условно разделить на две группы: «белые» и «серые».

☑️ К «белым» относятся однозначно легитимные индикаторы. Это, например, такие наборы, как:

• dax30 — список известных веб-страниц крупнейших компаний в Германии;

• security-provider-blogpost — список адресов блогов известных поставщиков средств безопасности;

• eicar.com — список хеш-сумм для тестового вредоносного ПО EICAR.

Такие индикаторы — наиболее полезный способ отсекать ложноположительные срабатывания средств защиты информации.

ℹ️ «Серые» же индикаторы сами по себе легитимны, однако могут участвовать во вредоносной активности. К спискам, содержащим подобные индикаторы, можно отнести, например:

• amazon_aws — список диапазонов IP-адресов Amazon Web Services;

• vpn-ipv4 — список диапазонов IP-адресов, принадлежащих распространенным провайдерам VPN;

• dynamic-dns — список известных провайдеров TLD и DDNS;

• url-shortener — список известных сервисов для сокращения URL.

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

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

💡 Несколько советов по использованию:

• Оцените полезность того или иного списка конкретно для своей инфраструктуры. Не стоит загружать все подряд.

• Обращайте внимание на обновляемость списков. Некоторые из них обновляются редко или не обновляются вообще.

#tool #tip #TI
@ptescalator

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

Одним из инструментов эксфильтрации может выступать утилита 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

C:\Windows\SysWOW64\smb_context.log — журнал событий smb от одного именитого антивирусного вендора.

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

Журнал может содержать следующие события:

PDMSmbFileAccessed
PDMSmbCreateFile
PDMSmbRenameFile

Пример:

<BeginStream>
PDMSmbFileAccessed("$windir\__1715675753.48",00000011000000000010010100100000,1399528814);
PDMSmbFileAccessed("$system32\cmpspy.dll",00001011110000000010001100100001,1399106043);
PDMSmbFileAccessed("$system32\reg.bat",00001011110000000010001100100001,1399106043);
<EndStream>

<BeginStream>
PDMSmbFileAccessed("$windir\psexesvc.exe",00001010100000000010001100100001,405741904);
<EndStream>

#tool #detect #hunt
@ptescalator

Наша практика показывает, что достаточно большое количество организаций все еще не установили обновления на свои публичные почтовые серверы Microsoft Exchange.

Вследствие этого у злоумышленников есть возможность получить в этих компаниях доступ к почтовой переписке. Для этого атакующие используют open-source-проект Exchange_SSRF.

Exchange_SSRF — это общедоступный Python-скрипт, который позволяет выгрузить почтовые ящики пользователей (по умолчанию 100) с сервера Microsoft Exchange жертвы. Фактически скрипт эксплуатирует две уязвимости (CVE-2021-34473 и CVE-2021-34523) из цепочки ProxyShell.

Для выгрузки файлов почтовых ящиков применяются методы FindItem, GetItem, GetAttachment, которые выполняются не под пользовательской учетной записью, а под системной NT AUTHORITY\SYSTEM, что хорошо видно в журналах Exchange Web Services (EWS):

C:\Program Files\Microsoft\Exchange Server\V15\Logging\EWS

Как правило, атакующие не модифицируют скрипт и используют его с заданным по умолчанию в исходном коде User-Agent с точкой в конце.

User-Agent:

Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36.

Стоит также отметить, что почти все зафиксированные атаки с применением этого скрипта были осуществлены с латвийских VPN-адресов сервиса Mullvad VPN.

Примеры опубликовали в Telegraph.

С2:

31.170.22.18
31.170.22.20
31.170.22.22
31.170.22.26
31.170.22.5
31.170.22.6

#tool #detect #hunt #win #dfir
@ptescalator

В дефолтных никсах мало форензик информации (vs win) и очень много полезных утилит. Например, есть «прекрасная» утилита, позволяющая дампить информацию с [ubw]tmp файлов в ASCII файлы, а также, дословно из мана:

…which can then be edited to remove bogus entries, and reintegrated using:
utmpdump -r < ascii_file > wtmp

Так что если в логи попал какой-то «кривой» айпишник, то нелегитимные «администраторы систем» могут его просто удалить, с чем мы и сталкивались на кейсах:

Дампинг:

utmpdump /var/log/wtmp

Через пайп грепаются строки с исключением в виде «кривого» айпишника и выхлоп в темпфайл:

| grep -v $EYE_PEE >/tmp/.wt 

Результат импортируется обратно:

&& utmpdump -r </tmp/.wt >/var/log/wtmp 

Затем удаляется темповый файл:

&& rm -f /tmp/.wt

Ну и конечно же, как написано в мане:

But be warned, utmpdump was written for debugging purposes only.

Детекты описаны уже очень давно, можно освежить их в памяти.

#tool #detect #hunt #nix #dfir
@ptescalator