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