Способы маскирования виртуальной среды 😷
В процессе анализа ВПО вы можете столкнуться с образцами, которые не будут полноценно работать в виртуальной среде. Все дело в том, что в них реализованы специальные механизмы, которые проверяют окружение, в котором работает образец.
Обнаружив, что он запущен в виртуальной среде, вредонос может либо прекращать свою работу, либо прикидываться легитимным ПО.
😂 Однако такие образцы можно попытаться обмануть — «убедить» их в том, что они запускаются на физическом устройстве.
Для этого нам понадобится всего одна правильно настроенная виртуальная машина (ВМ), которая будет скрывать свою виртуальную природу. Рассмотрим пару способов такой настройки.
Способ 1️⃣
Первый способ — публично доступный
Согласно документации к этому инструменту, добавляем в файл .vmx следующие свойства:
Если при запуске ВМ MAC-адрес поменялся на сгенерированный VMware, отредактируйте его прямо в GUI.
Далее нужно запустить в настроенной ВМ установочный скрипт
Если этот вариант не отработал, есть еще один.
Способ 2️⃣
Он более сложный, но и более надежный. Подход тот же — настройка ВМ, но в этом случае необходимо также пропатчить BIOS.
Требуется выполнить следующие шаги:
1. При создании новой ВМ не рекомендуется сразу выбирать установочный ISO-файл, иначе активируется
2. Чтобы сделать подставную ОС «достойной» жертвой вредоноса, необходимо выделить не менее 128 ГБ дискового пространства.
3. В
4. В параметрах настройки оборудования обязательно установите флажок
5. Как и в первом случае, поменяйте MAC-адрес на любой, кроме типичных для VMware
6. Затем добавьте установочный ISO-файл. Не забудьте про vmtools — их не нужно устанавливать.
7. После этого необходимо пропатчить BIOS ROM.
VMware BIOS ROM содержит строки, относящиеся к VMware и виртуализации. Их нужно убрать и заменить на какие-нибудь свои. Файл BIOS ROM находится в папке
При этом следует редактировать файл специальным инструментом —
После этого нужно собрать пропатченный BIOS через
8. В папке, где хранится ВМ, нужно найти файл .vmx. Заносим в него путь до пропатченного файла BIOS ROM:
Готово. Можно запускать виртуальную ОС. Теперь вредонос не поймет, что работает на ВМ, и отработает так, как должен.
#tips #malware
@ptescalator
В процессе анализа ВПО вы можете столкнуться с образцами, которые не будут полноценно работать в виртуальной среде. Все дело в том, что в них реализованы специальные механизмы, которые проверяют окружение, в котором работает образец.
Обнаружив, что он запущен в виртуальной среде, вредонос может либо прекращать свою работу, либо прикидываться легитимным ПО.
Для этого нам понадобится всего одна правильно настроенная виртуальная машина (ВМ), которая будет скрывать свою виртуальную природу. Рассмотрим пару способов такой настройки.
Способ 1️⃣
Первый способ — публично доступный
VmwareHardenedLoader. Требуется отредактировать файл .vmx и поменять MAC-адрес виртуальной машины на любой, не начинающийся с 00:05:69, 00:50:56, 00:1C:14, 00:0С:29.Согласно документации к этому инструменту, добавляем в файл .vmx следующие свойства:
hypervisor.cpuid.v0 = "FALSE"
board-id.reflectHost = "TRUE"
hw.model.reflectHost = "TRUE"
serialNumber.reflectHost = "TRUE"
isolation.tools.getPtrLocation.disable = "TRUE"
isolation.tools.setPtrLocation.disable = "TRUE"
isolation.tools.setVersion.disable = "TRUE"
isolation.tools.getVersion.disable = "TRUE"
monitor_control.disable_directexec = "TRUE"
monitor_control.disable_chksimd = "TRUE"
monitor_control.disable_ntreloc = "TRUE"
monitor_control.disable_selfmod = "TRUE"
monitor_control.disable_reloc = "TRUE"
monitor_control.disable_btinout = "TRUE"
monitor_control.disable_btmemspace = "TRUE"
monitor_control.disable_btpriv = "TRUE"
monitor_control.disable_btseg = "TRUE"
monitor_control.restrict_backdoor = "TRUE"
smbios.reflectHost = "TRUE"
SMBIOS.noOEMStrings = "TRUE"
scsi0:0.productID = "Your value"
scsi0:0.vendorID = "Your value"
ethernet0.address = "new mac address"
Если при запуске ВМ MAC-адрес поменялся на сгенерированный VMware, отредактируйте его прямо в GUI.
Далее нужно запустить в настроенной ВМ установочный скрипт
install.bat с привилегиями администратора. После этого можно начинать отладку. Теперь ВМ не должна быть видна образцу ВПО. Важно помнить, что устанавливать vmtools не следует. Если этот вариант не отработал, есть еще один.
Способ 2️⃣
Он более сложный, но и более надежный. Подход тот же — настройка ВМ, но в этом случае необходимо также пропатчить BIOS.
Требуется выполнить следующие шаги:
1. При создании новой ВМ не рекомендуется сразу выбирать установочный ISO-файл, иначе активируется
Windows Easy Install, который установит vmtools. 2. Чтобы сделать подставную ОС «достойной» жертвой вредоноса, необходимо выделить не менее 128 ГБ дискового пространства.
3. В
Firmware Type выберите BIOS.4. В параметрах настройки оборудования обязательно установите флажок
Virtualize Intel VT-x/EPT or AMD-V/RVI5. Как и в первом случае, поменяйте MAC-адрес на любой, кроме типичных для VMware
6. Затем добавьте установочный ISO-файл. Не забудьте про vmtools — их не нужно устанавливать.
7. После этого необходимо пропатчить BIOS ROM.
VMware BIOS ROM содержит строки, относящиеся к VMware и виртуализации. Их нужно убрать и заменить на какие-нибудь свои. Файл BIOS ROM находится в папке
C:\Program Files (x86)\VMware\VMware Workstation\x64. При этом следует редактировать файл специальным инструментом —
Phoenix BIOS Editor, чтобы не поменять внутренние чек-суммы файла. Откройте файл в редакторе, найдите окно с DMI Strings и поменяйте значения так, чтобы они не содержали «VMware» или «Virtual Platform».После этого нужно собрать пропатченный BIOS через
File → Build BIOS и где-нибудь сохранить его, не удаляя исходный.8. В папке, где хранится ВМ, нужно найти файл .vmx. Заносим в него путь до пропатченного файла BIOS ROM:
bios440.filename = "D:\<path_to_your_bios_file>\BIOS.440.PATCH.ROM", а также те же настройки, что и в способе 1, за исключением последних четырех строк.Готово. Можно запускать виртуальную ОС. Теперь вредонос не поймет, что работает на ВМ, и отработает так, как должен.
#tips #malware
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥25👍8❤4👏1🤡1
Slam screen locker. Что ты такое? ☹️
На очереди — fast malware analysis, проведенный одним воскресным вечером.
В наши сети залетел один интересный семпл, порождающий не менее интересный сетевой трафик (скриншот 1).
В этом файле (исполняемом .NET) содержится необфусцированный неймспейс Slam_Ransomware_Builder_2._0 (скриншот 2). Его название череcчур сильно похоже на известный в узких кругах Slam Ransomware, только версией побольше. Пример работы билдера 1.4 — по ссылке.
🏃♂️ Беглый анализ показал, что класс Slam_Ransomware_Builder_2._0.Lock отвечает за блокировку экрана, класс Slam_Ransomware_Builder_2._0.Chat реализует логику чата с жертвой локера.
Наибольший интерес вызывает класс ClientTest.ChatClient, содержащий реализацию сетевого протокола. По нему можно определить полный набор функций исследуемого ВПО.
• удаленное управление (например, LCD*<coord_x>*<coord_y> — эмуляция нажатия левой кнопки мыши, Command#<command> — выполнение команды в cmd, SetStartup*<prog_name> — добавление программы в автозапуск);
• отправка и получение файлов (например, ViewFiles*<dir_path>, клиент отсылает в ответ *FileTree*<files>*FileTree*, скриншот 3);
• снятие скриншотов (например, StartScreenShare*, StopScreenShare*, клиент отсылает в ответ SCREENSHOT*screen.jpg*<file_size>*<user_name>*<form_id>);
• кейлоггер (например, StartRealtimekeylogger*, StopRealtimekeylogger*, клиент отсылает в ответ SendrtKeylogger*<key_code>*).
И еще много всего — масштаб RAT поражает, любой клиент видео-конференц-связи позавидует.
😃 Самые неприятные и интересные пакости
Команда: LOCK*, LOCKUN*.
Действие: активировать или деактивировать локер рабочего стола.
Команда: textts*<text_to_speek>.
Действие: text to speech.
Команда: msgboxshow*<title>*<msg>*{Error,Information,Hand...}*<buttons>.
Действие: показать уведомление.
Команда: Wallpaper*<path_to_img>.
Действие: изменить изображение рабочего стола.
Команда: BSOD#.
Действие: вызвать синий экран смерти.
А на самом первом скриншоте представлен PING-PONG, который без труда покрывается правилами с флоубитами:
IOCs
Happy hunting!
#Hunt #C2 #Tips #IOC #detect #malware #network #suricata
@ptescalator
На очереди — fast malware analysis, проведенный одним воскресным вечером.
В наши сети залетел один интересный семпл, порождающий не менее интересный сетевой трафик (скриншот 1).
В этом файле (исполняемом .NET) содержится необфусцированный неймспейс Slam_Ransomware_Builder_2._0 (скриншот 2). Его название череcчур сильно похоже на известный в узких кругах Slam Ransomware, только версией побольше. Пример работы билдера 1.4 — по ссылке.
🏃♂️ Беглый анализ показал, что класс Slam_Ransomware_Builder_2._0.Lock отвечает за блокировку экрана, класс Slam_Ransomware_Builder_2._0.Chat реализует логику чата с жертвой локера.
Наибольший интерес вызывает класс ClientTest.ChatClient, содержащий реализацию сетевого протокола. По нему можно определить полный набор функций исследуемого ВПО.
• удаленное управление (например, LCD*<coord_x>*<coord_y> — эмуляция нажатия левой кнопки мыши, Command#<command> — выполнение команды в cmd, SetStartup*<prog_name> — добавление программы в автозапуск);
• отправка и получение файлов (например, ViewFiles*<dir_path>, клиент отсылает в ответ *FileTree*<files>*FileTree*, скриншот 3);
• снятие скриншотов (например, StartScreenShare*, StopScreenShare*, клиент отсылает в ответ SCREENSHOT*screen.jpg*<file_size>*<user_name>*<form_id>);
• кейлоггер (например, StartRealtimekeylogger*, StopRealtimekeylogger*, клиент отсылает в ответ SendrtKeylogger*<key_code>*).
И еще много всего — масштаб RAT поражает, любой клиент видео-конференц-связи позавидует.
Команда: LOCK*, LOCKUN*.
Действие: активировать или деактивировать локер рабочего стола.
Команда: textts*<text_to_speek>.
Действие: text to speech.
Команда: msgboxshow*<title>*<msg>*{Error,Information,Hand...}*<buttons>.
Действие: показать уведомление.
Команда: Wallpaper*<path_to_img>.
Действие: изменить изображение рабочего стола.
Команда: BSOD#.
Действие: вызвать синий экран смерти.
А на самом первом скриншоте представлен PING-PONG, который без труда покрывается правилами с флоубитами:
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg: "Slam V2.0 FB set ping"; flow: established, to_client; dsize: 8<>17; content: "?PING"; endswith; flowbits: set, slam_ping; flowbits: noalert; sid: 1; rev: 1; classtype: trojan-activity;)
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "Slam V2.0 ping-pong"; flow: established, to_server; dsize: 8<>17; content: "PONG#"; startswith; content: "#"; endswith; flowbits: isset, slam_ping; threshold: type limit, track by_dst, count 2, seconds 240; sid: 2; rev: 1; classtype: trojan-activity;)
IOCs
SHA-256: e42088a37531929e3e775bdfacc5a3ee974e4f59d5290907c2131f434eef345b
C2: 77.231.153.42
Happy hunting!
#Hunt #C2 #Tips #IOC #detect #malware #network #suricata
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23👍9👌5❤1
📫 X-фильтрация данных пользователя
В процессе анализа почтового трафика мы периодически сталкиваемся с реализацией необычных вредоносных техник. Сегодня хочется рассказать про то, как злоумышленники эксфильтруют полезные данные через X-заголовки писем электронной почты.
В электронных письмах, помимо обязательных заголовков, таких как
Каждый сервис и организация может выставлять свои X-заголовки без явных ограничений, поэтому их количество на данный момент можно исчислять тысячами. Описать и понять содержимое каждого из них — невероятно сложная задача. Этим и пользуются злоумышленники. Они создают собственные X-заголовки и помещают в них закодированные полезные данные, которые надо эксфильтровать.
😠 Например, заголовки такого «необычного» письма могут выглядеть следующим образом:
Как видите, в X-заголовках множество разных типов информации: числа, строки, что-то вроде булевых значений, закодированные последовательности и так далее.
Среди них сложно найти тот заголовок, который явно несет угрозу. В данном случае «плохим» оказался заголовок
😑 Чтобы не вызывать подозрений у систем защиты почты, злоумышленники также снабжают письмо максимально безобидным текстом, не добавляя при этом подозрительных составляющих по типу html-частей и вложений.
Таким образом получается крайне удобный и скрытый способ эксфильтрации данных для злоумышленников. Такая техника зачастую используется при корпоративном шпионаже, когда инсайдер имеет законный доступ к системам электронной почты. Он может встраивать полезные данные в заголовки, отправляя их под видом обычного делового письма.
Стоит отметить, что у данного способа есть одно основное ограничение — это передача только небольших объемов данных. То есть это хорошо подойдет для эксфильтрации ключей шифрования, учетных данных и тому подобного.
Однако, если злоумышленник попытается передавать таким способом большие блоки данных (например, файлы), то это будет сильно заметно на фоне всего почтового трафика.
😱 Что делать:
1. Внедрить методы анализа содержимого заголовков писем. Лучше всего — c использованием DLP системы.
2. Обращать внимание на необычные X-заголовки в исходящих письмах. Сделать это можно, например, посчитав статистику упоминания таких заголовков за определенный период, где самые неупоминаемые — самые подозрительные.
3. Следить за потоками писем с одинаковым контентом, отправляемых на один адрес.
#Detect #Tip
@ptescalator
В процессе анализа почтового трафика мы периодически сталкиваемся с реализацией необычных вредоносных техник. Сегодня хочется рассказать про то, как злоумышленники эксфильтруют полезные данные через X-заголовки писем электронной почты.
В электронных письмах, помимо обязательных заголовков, таких как
From, Date и т. п., встречаются заголовки с префиксом X. Они несут в себе дополнительную информацию, например сведения о работе почтовых защитных механизмов, служебные идентификаторы, различные метаданные об отправителе.Каждый сервис и организация может выставлять свои X-заголовки без явных ограничений, поэтому их количество на данный момент можно исчислять тысячами. Описать и понять содержимое каждого из них — невероятно сложная задача. Этим и пользуются злоумышленники. Они создают собственные X-заголовки и помещают в них закодированные полезные данные, которые надо эксфильтровать.
Received: from SB1P221MB1152.NAMP221.PROD.OUTLOOK.COM
(3613:10b6:806:388::20) by BD0P221MB0288.NAMP221.PROD.OUTLOOK.COM with
HTTPS; Thu, 20 Mar 2024 21:28:15 +0000
...
From: John Doe <[email protected]>
To: John Goe <[email protected]>
Subject: New Test
Date: Thu, 20 Mar 2024 21:28:15 +0000
Accept-Language: en-US
Content-Language: en-US
X-Ms-Exchange-Organization-Authmechanism: 04
X-Ms-Exchange-Organization-Authsource: BD0P221MB0288.NAMP221.PROD.OUTLOOK.COM
X-Ms-Has-Attach: yes
...
X-Entity-ID: WABIHdrtPzUrGNbwVwoPTQ==
X-Trusted-Header: c2VjcmV0X2xvZ2luOnNlY3JldF9wYXNzd29yZA==
X-Ms-Exchange-Organization-Scl: -1
Как видите, в X-заголовках множество разных типов информации: числа, строки, что-то вроде булевых значений, закодированные последовательности и так далее.
Среди них сложно найти тот заголовок, который явно несет угрозу. В данном случае «плохим» оказался заголовок
X-Trusted-Header (в нем лежат учетные данные пользователя), который по контенту абсолютно сравним с легитимным X-Entity-ID.😑 Чтобы не вызывать подозрений у систем защиты почты, злоумышленники также снабжают письмо максимально безобидным текстом, не добавляя при этом подозрительных составляющих по типу html-частей и вложений.
Таким образом получается крайне удобный и скрытый способ эксфильтрации данных для злоумышленников. Такая техника зачастую используется при корпоративном шпионаже, когда инсайдер имеет законный доступ к системам электронной почты. Он может встраивать полезные данные в заголовки, отправляя их под видом обычного делового письма.
Стоит отметить, что у данного способа есть одно основное ограничение — это передача только небольших объемов данных. То есть это хорошо подойдет для эксфильтрации ключей шифрования, учетных данных и тому подобного.
Однако, если злоумышленник попытается передавать таким способом большие блоки данных (например, файлы), то это будет сильно заметно на фоне всего почтового трафика.
😱 Что делать:
1. Внедрить методы анализа содержимого заголовков писем. Лучше всего — c использованием DLP системы.
2. Обращать внимание на необычные X-заголовки в исходящих письмах. Сделать это можно, например, посчитав статистику упоминания таких заголовков за определенный период, где самые неупоминаемые — самые подозрительные.
3. Следить за потоками писем с одинаковым контентом, отправляемых на один адрес.
#Detect #Tip
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15🔥5👏3
Как вы называете атакующих? 🥷
Anonymous Poll
9%
Hackers 🇬🇧
4%
АПТ 🎯
4%
Кекеры 😃
20%
Хацкеры 👶
2%
Крякеры 🦆
33%
Злоумышленники 😏
3%
Враги 👊
6%
Хахакеры 🤡
13%
Внештатные аудиторы безопасности 😼
7%
Злодеи 😡
😁17🤯5⚡4🔥2👍1👏1
Об обфусцированном батнике замолвите слово...
Этот пост публикуем вдогонку к недавнему про EXE-шник, скрытый под хексдампом в Base64-запросе на создание сертификата: разумеется, самостоятельно в такой схеме он не запустится. Изначально CSR-файл являлся лишь частью batch-скрипта, упакованного в RAR-архив, который назвали
📂 Открыть его удалось только с помощью WinRAR и UnRAR на Linux, дефолтный распаковщик Винды и 7-Zip теряются при виде архива, как показано на первом скриншоте (UX этого семпла на очень низком уровне).
Внутри архива находится batch-файл
Для начинающего администратора Windows эти кракозябры могут быть непонятны, но на самом деле это валидный батник, просто немного обфусцированный. Основная операция в данном скрипте — это извлечение подстроки из исходной строки, а затем склейка и интерпретация полученного результата (подробнее об операциях над строками в batch-файлах можно прочитать здесь).
Получив эти знания, можно вооружиться питоном и начать представленный скрипт, но мы поступили более хитро и воспользовались этим инструментом.
Применим деобфускатор к файлу:
Подчистив вывод, получаем исходный скрипт, представленный на третьем скриншоте (C:\Users\Public заменено на %PUBLIC% для краткости). Самое забавное, что обфускатор BatCloak не спросил малварщика и оставил в его скрипте рекламу (вот и пользуйся после такого опенсорсом!).
Как видно, скрипт копирует cmd.exe в файл alpha.exe с помощью утилиты extrac32 (для обхода средств защиты), проделывает то же самое с certutil -> kn, а затем распаковывает Base64 и хексдамп с помощью нового certutil и запускает результирующий EXE-шник. Это же поведение можно увидеть и запустив файл в песочнице, например в PT Sandbox (скриншот 4).
Но поведение — это отдельная тема. Как же детектировать обфусцированный батник? Родилась идея следующего YARA-правила:
Как вам эта информация, мотивирует к переходу на Linux? 🧐
#Detect #Yara
@ptescalator
Этот пост публикуем вдогонку к недавнему про EXE-шник, скрытый под хексдампом в Base64-запросе на создание сертификата: разумеется, самостоятельно в такой схеме он не запустится. Изначально CSR-файл являлся лишь частью batch-скрипта, упакованного в RAR-архив, который назвали
Serkan_Yalgi.Tar.Внутри архива находится batch-файл
Serkan_Yalgi.cmd, на втором скриншоте представлен фрагмент его содержимого. И такого безобразия там примерно 400 строк, остальные 115 000 строк занимает упомянутый в прошлом посте EXE в Base64.Для начинающего администратора Windows эти кракозябры могут быть непонятны, но на самом деле это валидный батник, просто немного обфусцированный. Основная операция в данном скрипте — это извлечение подстроки из исходной строки, а затем склейка и интерпретация полученного результата (подробнее об операциях над строками в batch-файлах можно прочитать здесь).
Получив эти знания, можно вооружиться питоном и начать представленный скрипт, но мы поступили более хитро и воспользовались этим инструментом.
Применим деобфускатор к файлу:
python batch_interpreter.py –file Serkan_Yalgi.cmd
Подчистив вывод, получаем исходный скрипт, представленный на третьем скриншоте (C:\Users\Public заменено на %PUBLIC% для краткости). Самое забавное, что обфускатор BatCloak не спросил малварщика и оставил в его скрипте рекламу (вот и пользуйся после такого опенсорсом!).
Как видно, скрипт копирует cmd.exe в файл alpha.exe с помощью утилиты extrac32 (для обхода средств защиты), проделывает то же самое с certutil -> kn, а затем распаковывает Base64 и хексдамп с помощью нового certutil и запускает результирующий EXE-шник. Это же поведение можно увидеть и запустив файл в песочнице, например в PT Sandbox (скриншот 4).
Но поведение — это отдельная тема. Как же детектировать обфусцированный батник? Родилась идея следующего YARA-правила:
strings:
$subs = /:~\ *(-|\+)?\d{1,2},\ *(-|\+)?\d{1,3}%/
condition:
#subs > 100
Как вам эта информация, мотивирует к переходу на Linux? 🧐
#Detect #Yara
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21👍12❤9💯1
Слышали ли вы про публичный репозиторий Suricata-правил Attack Detection?
Да это яяяя Внутри большой команды PT Expert Security Center есть отдельная группа экспертов, главная задача которых — разрабатывать правила обнаружения для сетевых средств защиты. Вы уже наверняка знакомы с некоторыми постами про сетевые артефакты от этой команды.
Спустя два года перерыва мы возвращаемся к вам с обновленным порталом и снова начинаем публиковать части своей экспертизы в виде Suricata-правил 🔥
Из обновлений:
1. Правила для последних уязвимостей.
2. Правила для обнаружения крайне популярных в узких кругах инструментов Croc и gsocket.
3. А также несколько правил для выявления горизонтального перемещения в сети Active Directory.
Настройте suricata-update на поддержку официального источника правил ptrules/open и следите за обновлениями на нашей странице в X.
👋🏼 Stay tuned
#suricata #network #signature #rules
@ptescalator
Спустя два года перерыва мы возвращаемся к вам с обновленным порталом и снова начинаем публиковать части своей экспертизы в виде Suricata-правил 🔥
Из обновлений:
1. Правила для последних уязвимостей.
2. Правила для обнаружения крайне популярных в узких кругах инструментов Croc и gsocket.
3. А также несколько правил для выявления горизонтального перемещения в сети Active Directory.
Настройте suricata-update на поддержку официального источника правил ptrules/open и следите за обновлениями на нашей странице в X.
👋🏼 Stay tuned
#suricata #network #signature #rules
@ptescalator
🔥33👍15❤7
Снова ловим багхантеров 💀
В одном из предыдущих постов мы писали про следы багбаунти-деятельности по отношению к «Яндексу». История повторилась, но уже с нами.
Сработал алерт на активность, связанную с новыми вредоносными пакетами
Человеку — большое уважение: озаботился покупкой домена, еще и перед этим, вероятно, ознакомился с атаками, проводимыми ранее... Отправляем репорт в Python Package Index, уведомляем коллег из Innostage.
🐈 Подозреваем, автор читал мартовскую статью Checkmarx, где злоумышленник «протроянил» пакет colorama. Был сделан pull request, который, помимо всего прочего, в ссылках на дистрибутивы легитимный домен
Хоть в описании проекта и упоминается, что это багбаунти, в качестве нагрузки человек использовал не отстук (как это делал багхантер из истории с «Яндексом»), а реверс-шеллы (на скриншотах). Не совсем исследовательский подход, к сожалению.
Далее к пакетам🤨 Занятно. Нагрузка все та же — реверс-шеллы.
Домен🤬 . Что-ж...
———
PT PyAnalysis. Профессионально отслеживаем багхантеров с 2024 года.
#ti #pypi #pyanalysis
@ptescalator
В одном из предыдущих постов мы писали про следы багбаунти-деятельности по отношению к «Яндексу». История повторилась, но уже с нами.
Сработал алерт на активность, связанную с новыми вредоносными пакетами
innostage и innostage_group. История нетипичная: почта у разработчика — [email protected] (о, русскоговорящий человек!), а нагрузка скачивается с доменов files.inostage.ru (мимикрия под innostage-group.ru) и files.pythonhosted.ru (мимикрия под files.pythonhosted.org). Человеку — большое уважение: озаботился покупкой домена, еще и перед этим, вероятно, ознакомился с атаками, проводимыми ранее... Отправляем репорт в Python Package Index, уведомляем коллег из Innostage.
files.pythonhosted.org поменял на управляемый атакующим files.pypihosted.org.Хоть в описании проекта и упоминается, что это багбаунти, в качестве нагрузки человек использовал не отстук (как это делал багхантер из истории с «Яндексом»), а реверс-шеллы (на скриншотах). Не совсем исследовательский подход, к сожалению.
Далее к пакетам
innostage и innostage_group прибавились cyberart, ... posi, maxpatrol и ptsecurity Домен
inostage.ru уже ранее светился на Standoff. Получается, снова обнаружили деятельность багхантеров, в этот раз еще и помешав исследованию ———
#ti #pypi #pyanalysis
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
😁19🔥13❤7👍4💩3👀2
Какой уязвимый сервис вы любите у себя на периметре? 🥰
Anonymous Poll
16%
Звездный Exchange (Proxyshell/Proxylogon) 🙂
10%
Непрощающий SMB v1.0 (MS17-010, EternalBlue) 🙅♂️
2%
Добродушный NetScaler 😇
8%
Всезнающее семейство Atlassian 🤓
22%
Ламповый плагин к Bitrix 💡
4%
Краснокожий Apache 😡
4%
Гостеприимный RDP -> RDG 👋
5%
Многоликий vCenter 🗿
29%
Я не из этих... 😐
🍓6😁5❤2🐳2🙈2👍1
Ловите продолжение
Если вдруг подобный вредонос смог пройти все рубежи защиты, попасть на тачку пользователя и начать там работать, не все потеряно!
Вы же обратили внимание, что на первом этапе вредоносный BAT-файл копировал и переименовывал пару системных файлов (
cmd.exe и certutil.exe), которые затем использовал?Выявление такого поведения несложно автоматизировать
Хорошо настроенная служба Microsoft Sysmon позволяет не только журналировать запуск процессов и параметры командной строки, но и фиксировать такие интересные данные из свойств файла, как его оригинальное имя (смотрите скриншоты 1 и 2).
А значит, достаточно просто сравнить значения двух полей в событии, чтобы вовремя выявить использование подобной хакерской техники (она, кстати, называется «Маскировка: Переименование системных утилит»).
В составе пакетов экспертизы MaxPatrol SIEM у нас есть правило и на этот случай —
Copied_or_Renamed_Executable.А если у вас нет нашего продукта, можно взять за основу для своих детектов одно из SIGMA-правил proc_creation_win_renamed_binary_highly_relevant.
#Detect #Sigma #Rules
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13🤩7✍6👍2😁1
Как починить CFG 🔧
В процессе реверса ВПО мы встречаемся со случаями, когда обфускация мешает понять общий алгоритм работы. Один из примеров — создание двух последовательных противоположных условных переходов в одну точку.
Схематично это выглядит так:
То есть IDA при анализе кода идет сначала по ветке
Далее, встретив противоположный условный переход, она снова идет по ветке
При живом исполнении в независимости от состояния флагов будет выполнен переход на операнд, то есть выполнение будет как на скриншоте 2, если мы подправим control flow.
Трудность при исследовании таких шеллкодов в том, что переходов может быть много и каждый раз анализ будет о них спотыкаться. Можно попробовать починить вручную, но если таких блоков будут сотни?
✍️ Чтобы справиться с этим, напишем несложный скрипт на
Сначала составим список противоположных условных переходов и положим его в функцию, которая будет сверять две последовательные инструкции со списком:
Будем последовательно проходить каждую инструкцию до тех пор, пока не встретим нужные либо не упремся в лимит.
🧐 С помощью метода
С помощью
Затем исправляем условные переходы и просим IDA проанализировать новый код. Это необходимо, чтобы можно было найти дальнейшие блоки обфускации:
🗂 Методом
Таким образом, этот скрипт позволяет из обфусцированного кода получить нормальный ASM-код, как на скриншоте 3.
Иногда после него остаются единичные нераспознанные байты, но их легко поправить. Из этого кода можно создать функцию, декомпилировать ее и проанализировать (как на скриншоте 4).
Изучайте IDAPython, пишите скрипты. Happy reversing!
#tip #reverse #idapython
@ptescalator
В процессе реверса ВПО мы встречаемся со случаями, когда обфускация мешает понять общий алгоритм работы. Один из примеров — создание двух последовательных противоположных условных переходов в одну точку.
Схематично это выглядит так:
start:
jnX labelA
jX labelA
labelA:
<bytes>
То есть IDA при анализе кода идет сначала по ветке
False и создает код там, откладывая ветку True на потом. Встретив инструкцию jnX, IDA создает код сразу после текущей.Далее, встретив противоположный условный переход, она снова идет по ветке
False и создает код на следующем адресе, построив мусорную инструкцию, после которой дизассемблировать уже нельзя. Тогда IDA возвращается к отложенной на потом очереди и берет адрес оттуда, но беда в том, что там код уже создан, а значит анализ завершается (хорошо видно на скриншоте 1).При живом исполнении в независимости от состояния флагов будет выполнен переход на операнд, то есть выполнение будет как на скриншоте 2, если мы подправим control flow.
Трудность при исследовании таких шеллкодов в том, что переходов может быть много и каждый раз анализ будет о них спотыкаться. Можно попробовать починить вручную, но если таких блоков будут сотни?
✍️ Чтобы справиться с этим, напишем несложный скрипт на
IDAPython, который исправит проблему автоматически. Задача — найти эти блоки и пропатчить их.Сначала составим список противоположных условных переходов и положим его в функцию, которая будет сверять две последовательные инструкции со списком:
def c_jumps(addr, n_addr):
ops = [
("jz", "jnz"),
("jnz", "jz"),
("je", "jne"),
("jne", "je"),
...
]
if (ida_ua.print_insn_mnem(addr), ida_ua.print_insn_mnem(n_addr)) in ops:
return True
return False
Будем последовательно проходить каждую инструкцию до тех пор, пока не встретим нужные либо не упремся в лимит.
def deobf(start, limit=BADADDR):
while addr != BADADDR:
n_addr = ida_search.find_code(addr, ida_search.SEARCH_DOWN)
if n_addr == BADADDR:
break
if not c_jumps(addr, n_addr):
addr = n_addr
continue
🧐 С помощью метода
find_code из модуля ida_search находим следующий адрес, на котором есть код, а с помощью функции c_jumps проверяем, являются ли инструкции на этом и следующем адресе противоположными прыжками. Найдя их, мы должны проверить, указывают ли эти прыжки на одну точку (то есть равны ли их операнды):
o1 = get_operand_value(addr, 0)
o2 = get_operand_value(n_addr, 0)
if o1 != o2:
addr = n_addr
continue
insn = ida_ua.insn_t()
l1 = ida_ua.decode_insn(insn, addr)
l2 = ida_ua.decode_insn(insn, n_addr)
С помощью
get_operand_value получаем значение операндов (у jX и jXX он один) и проверяем их равенство. Чтобы определить длину отрезка, который нужно пропатчить, с помощью decode_insn из ida_ua находим длины инструкций.Затем исправляем условные переходы и просим IDA проанализировать новый код. Это необходимо, чтобы можно было найти дальнейшие блоки обфускации:
after_addr = n_addr + l2
ida_bytes.patch_bytes(addr, bytes([0x90] * (l1 + l2 + 1)))
ida_auto.auto_wait()
ida_bytes.del_items(after_addr, ida_bytes.DELIT_EXPAND)
ida_auto.auto_wait()
ida_ua.create_insn(o1)
addr = o1
ida_auto.auto_wait()
🗂 Методом
patch_bytes из ida_bytes мы патчим инструкции, с помощью auto_wait из ida_auto просим IDA проанализировать новый код, затем, используя del_items, удаляем мусорные инструкции, созданные при первичном анализе, и снова анализируем. С помощью create_insn создаем валидную инструкцию там, куда указывали условные переходы, и переанализируем в последний раз.Таким образом, этот скрипт позволяет из обфусцированного кода получить нормальный ASM-код, как на скриншоте 3.
Иногда после него остаются единичные нераспознанные байты, но их легко поправить. Из этого кода можно создать функцию, декомпилировать ее и проанализировать (как на скриншоте 4).
Изучайте IDAPython, пишите скрипты. Happy reversing!
#tip #reverse #idapython
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19👍7💯6👾3
Бесконечная череда переходов ♾️
Довольно часто злоумышленники, отправляя фишинговые ссылки по почте, не прикрепляют их в явном виде к электронному письму, а используют разнообразные техники перенаправления. Подозрительный домен прячется от пользователя и средств защиты, осуществляющих статический анализ ссылок, и увеличивает шансы поймать жертву.
Часто киберпреступники используют один уровень перенаправления с легитимного ресурса на вредоносный. Но нам посчастливилось разобрать кейс, где злоумышленник использовал сразу пять последовательных — и, самое главное, разнообразных — техник перенаправления на вредоносный ресурс.
1️⃣ Перенаправление через TikTok
Ссылка начинается с конструкции:
TikTok дает возможность поместить в описание профиля (параметр
Итак, TikTok вместо смешных рилсов переправляет нас на...
2️⃣ Google AMP
Google AMP — средство ускоренного просмотра веб-страниц, поддерживающих ряд специально созданных для этого ускорения ограничений. Примечательно, что страница загружается не с самого домена, на котором она размещена, а из кэша Google. Собственно, первая интересующая нас веб-страница вполне удовлетворяет этим требованиям, поскольку содержит всего несколько строк JavaScript-кода.
3️⃣ Первый подозрительный домен
Содержит следующий код:
При выполнении, когда истекает тайм-аут в 2 секунды, открывается новая вкладка с
4️⃣ Переход на secondBase64Url
На данном этапе нам встречается использование Cloudflare Turnstile — встраиваемой мини-капчи, не требующей перевода трафика через Cloudflare (пример интерфейса на скриншоте 1). При ручном анализе кода этой страницы мы уже можем распарсить еще один URL-адрес, но, чтобы все-таки совершить переход на него, надо учиться проходить эту капчу.
5️⃣ Традиционный 3XX код ответа страницы
Здесь все просто: на предыдущем этапе URL из кода через стандартный ответ 302 перенаправляет на конечную фишинговую страницу сбора паролей, имитирующую окно авторизации Microsoft Outlook. Ее интерфейс в окне браузера представлен на скриншоте 2.
💁♂️ Советы:
• При анализе фишингового URL-адреса стоит обратить внимание на покрытие обнаруженных техник против переходов (включение пауз, капч, открытие новых вкладок) имеющимися средствами защиты информации: если используемое СЗИ при автоматическом переходе по ссылке не умеет их обходить, то полезным может оказаться просто их детектирование и блокировка соответствующего почтового сообщения.
• Если вы (как пользователь) нажали на подобную ссылку — обратите внимание, насколько часто менялся URL в адресной строке браузера и сколько дополнительных действий было сделано вами и на стороне браузера.
#tip #phishing #web
@ptescalator
Довольно часто злоумышленники, отправляя фишинговые ссылки по почте, не прикрепляют их в явном виде к электронному письму, а используют разнообразные техники перенаправления. Подозрительный домен прячется от пользователя и средств защиты, осуществляющих статический анализ ссылок, и увеличивает шансы поймать жертву.
Часто киберпреступники используют один уровень перенаправления с легитимного ресурса на вредоносный. Но нам посчастливилось разобрать кейс, где злоумышленник использовал сразу пять последовательных — и, самое главное, разнообразных — техник перенаправления на вредоносный ресурс.
1️⃣ Перенаправление через TikTok
Ссылка начинается с конструкции:
https://www.tiktok.com/link/v2?aid=1988&lang=en&scene=bio_url&target=
TikTok дает возможность поместить в описание профиля (параметр
bio_url) ссылки на внешние ресурсы, и перенаправление на них производится по приведенному выше URL-адресу. Кстати, aid=1988 видим не только в рамках исследования этого кейса, но и в отчетах других вендоров. Единственный необязательный параметр в этом запросе — lang, но, видимо, он, так же как и ID, перекочевал и образовал устойчивый префикс в фишинговых кейсах. Это наводит на мысль добавить его в качестве шаблона для средств защиты.Итак, TikTok вместо смешных рилсов переправляет нас на...
2️⃣ Google AMP
https://www.google.ca/url?q=amp/s/<phishing_url>
Google AMP — средство ускоренного просмотра веб-страниц, поддерживающих ряд специально созданных для этого ускорения ограничений. Примечательно, что страница загружается не с самого домена, на котором она размещена, а из кэша Google. Собственно, первая интересующая нас веб-страница вполне удовлетворяет этим требованиям, поскольку содержит всего несколько строк JavaScript-кода.
3️⃣ Первый подозрительный домен
Содержит следующий код:
<script type="text/javascript">
var firstBase64Url = "aHR0cHM6Ly94LmNvbQ==";
var secondBase64Url = "<Ещё один вредоносный ресурс>";
// Load the first URL for a few seconds
setTimeout(function() {
window.open(atob(firstBase64Url), '_blank');
}, 2000); // 2000 milliseconds = 2 seconds
// After the specified time, load the second URL
setTimeout(function() {
window.location.href = atob(secondBase64Url) + "?qrc=" + window.location.hash.substr(1);
}, 2000); // 2000 milliseconds = 2 seconds
</script>
При выполнении, когда истекает тайм-аут в 2 секунды, открывается новая вкладка с
firstBase64Url (как несложно проверить, это https://x.com/, еще один легитимный ресурс), а в открытой вкладке происходит перенаправление на secondBase64Url. Обе техники — открытие новой браузерной вкладки и включение тайм-аута — нужны для усложнения анализа веб-краулерами.4️⃣ Переход на secondBase64Url
На данном этапе нам встречается использование Cloudflare Turnstile — встраиваемой мини-капчи, не требующей перевода трафика через Cloudflare (пример интерфейса на скриншоте 1). При ручном анализе кода этой страницы мы уже можем распарсить еще один URL-адрес, но, чтобы все-таки совершить переход на него, надо учиться проходить эту капчу.
5️⃣ Традиционный 3XX код ответа страницы
Здесь все просто: на предыдущем этапе URL из кода через стандартный ответ 302 перенаправляет на конечную фишинговую страницу сбора паролей, имитирующую окно авторизации Microsoft Outlook. Ее интерфейс в окне браузера представлен на скриншоте 2.
💁♂️ Советы:
• При анализе фишингового URL-адреса стоит обратить внимание на покрытие обнаруженных техник против переходов (включение пауз, капч, открытие новых вкладок) имеющимися средствами защиты информации: если используемое СЗИ при автоматическом переходе по ссылке не умеет их обходить, то полезным может оказаться просто их детектирование и блокировка соответствующего почтового сообщения.
• Если вы (как пользователь) нажали на подобную ссылку — обратите внимание, насколько часто менялся URL в адресной строке браузера и сколько дополнительных действий было сделано вами и на стороне браузера.
#tip #phishing #web
@ptescalator
🔥11👍8❤4⚡3🍌1