Уже не Rezet, или Новые атаки Rare Wolf 🐺
Группа киберразведки PT ESC продолжает фиксировать атаки группировки Rare Wolf: так, в конце мая злоумышленники рассылали фишинговые письма от имени
Группировка все так же доставляет вредоносный SCR-файл внутри архива, пароль к которому указан в тексте письма. При запуске SCR-файл отвлекает внимание жертвы, открывая документ-приманку, и одновременно скачивает на узел архив с PowerShell- и BAT-скриптами. В этот раз для распаковки скриптов используется скрытая папка
Rare Wolf по-прежнему собирает системную информацию, в том числе дампы реестров SAM и SYSTEM, сканирует локальные подсети в попытке скопировать файлы с других устройств и скрытно устанавливает AnyDesk для удаленного доступа.
🕗 Следует отметить, что сканирование локальной подсети проходит по жестко заданным IP-адресам и занимает около 9–10 минут, что существенно превышает лимиты динамического анализа большинства публичных песочниц. Обычно такие сервисы ограничивают время эмуляции несколькими минутами (от 1 до 6), а в расширенных режимах — не более 10–12 минут. Вероятно, цель подобных задержек — не дать песочницам зафиксировать дальнейшие действия вредоносных файлов.
🙅♂️ Единственными заметными изменениями стали отказ от файла
Для этого злоумышленники устанавливают на зараженном устройстве демон sshd и исполняемый файл tuna.exe, прописывают в firewall разрешение на входящий TCP-порт 22 и настраивают ключевую аутентификацию, обеспечивая автоматический запуск службы sshd при старте системы и поддерживая обратное SSH-соединение с сервером управления. Tuna при этом инициирует исходящее соединение к C2 и проксирует весь трафик на локальный демон sshd, обеспечивая скрытый и защищенный канал.
😠 При попытке вручную вызвать tuna (например, выполнить в командной строке
В марте этого года группировка также предпринимала попытку рассылки вирусного ПО, однако пароль от архива не совпал с тем, что был указан злоумышленниками в тексте письма. А используемый домен
IoCs
#TI #APT #phishing #malware #ioc
@ptescalator
Группа киберразведки PT ESC продолжает фиксировать атаки группировки Rare Wolf: так, в конце мая злоумышленники рассылали фишинговые письма от имени
antey-almaz-info.site в адрес компаний военно-промышленного комплекса. Текущая кампания очень похожа на ту, что мы описывали в конце января (скриншот 1).Группировка все так же доставляет вредоносный SCR-файл внутри архива, пароль к которому указан в тексте письма. При запуске SCR-файл отвлекает внимание жертвы, открывая документ-приманку, и одновременно скачивает на узел архив с PowerShell- и BAT-скриптами. В этот раз для распаковки скриптов используется скрытая папка
C:\Users\admin\Window (скриншоты 2–3).Rare Wolf по-прежнему собирает системную информацию, в том числе дампы реестров SAM и SYSTEM, сканирует локальные подсети в попытке скопировать файлы с других устройств и скрытно устанавливает AnyDesk для удаленного доступа.
rezet.cmd, использовавшегося ранее в атаках, и переход с публичного туннелирования через ngrok на собственный обратный SSH-туннель с использованием Tuna и штатного sshd — это повышает скрытность и надежность канала связи с C2-сервером. Для этого злоумышленники устанавливают на зараженном устройстве демон sshd и исполняемый файл tuna.exe, прописывают в firewall разрешение на входящий TCP-порт 22 и настраивают ключевую аутентификацию, обеспечивая автоматический запуск службы sshd при старте системы и поддерживая обратное SSH-соединение с сервером управления. Tuna при этом инициирует исходящее соединение к C2 и проксирует весь трафик на локальный демон sshd, обеспечивая скрытый и защищенный канал.
tuna tcp 22), можно увидеть адрес электронной почты, который используют злоумышленники. На скриншоте также видна ошибка, сообщающая, что учетная запись неактивна — возможно, они просто забыли продлить оплату (скриншот 4).В марте этого года группировка также предпринимала попытку рассылки вирусного ПО, однако пароль от архива не совпал с тем, что был указан злоумышленниками в тексте письма. А используемый домен
almaz-antey-info.online представлял слегка измененный вариант домена, используемого в майских атаках (скриншот 5).IoCs
[email protected]
almaz-antey-info.online
antey-almaz-info.site
b7543b3e0c3fa6bd8973dde12258c7f7
fc0b6c43185061c2b3b11ab0bfdf924f
9eb2c87299e3b1d86268ab1752b83502
#TI #APT #phishing #malware #ioc
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23👍12👏7❤4😁2🎉1🤡1
DarkGaboon. Яд кибергадюки в цифровых жилах российских компаний 🐍
В январе текущего года группа киберразведки TI-департамента PT ESC разоблачила ранее неизвестную финансово мотивированную APT-группировку DarkGaboon, кибератаки которой в отношении российских компаний удалось отследить до весны 2023 года.
Изучению подверглись эволюция вредоносного арсенала, миграция инфраструктуры и TTP группировки, но для полного восстановления kill chain не хватало инструментов и техник конечного импакта. Однако уже этой весной департамент комплексного реагирования на киберугрозы непосредственно столкнулся с кибератаками DarkGaboon в ходе расследования инцидентов. Недостающими элементами kill-chain-пазла оказались сканер сетевых шар и шифровальщик LockBit.
📥 Эксперты PT ESC обнаружили, что в качестве вектора проникновения DarkGaboon использует электронные письма c замаскированными под финансовые документы RAT-троянами Revenge и XWorm, которые рассылаются с расположенного в России SMTP-сервера (
Для управления RAT-сессиями на зараженных хостах группировка использует зарегистрированный на Сейшелах Windows-хост с RDP-подключением, арендованный у американского провайдера хостинга Nybula LLC, и группу DDNS-доменов.
Артефакты, обнаруженные экспертами PT ESC на инцидентах, позволили связать DarkGaboon с целой серией кибератак 2023–2025 годов на российские компании с использованием шифровальщика LockBit.
Подробности — в нашем блоге.
#TI #APT #Malware
@ptescalator
В январе текущего года группа киберразведки TI-департамента PT ESC разоблачила ранее неизвестную финансово мотивированную APT-группировку DarkGaboon, кибератаки которой в отношении российских компаний удалось отследить до весны 2023 года.
Изучению подверглись эволюция вредоносного арсенала, миграция инфраструктуры и TTP группировки, но для полного восстановления kill chain не хватало инструментов и техник конечного импакта. Однако уже этой весной департамент комплексного реагирования на киберугрозы непосредственно столкнулся с кибератаками DarkGaboon в ходе расследования инцидентов. Недостающими элементами kill-chain-пазла оказались сканер сетевых шар и шифровальщик LockBit.
📥 Эксперты PT ESC обнаружили, что в качестве вектора проникновения DarkGaboon использует электронные письма c замаскированными под финансовые документы RAT-троянами Revenge и XWorm, которые рассылаются с расположенного в России SMTP-сервера (
185.185.70.85) и более 50 связанных с ним доменов в российской доменной зоне.Для управления RAT-сессиями на зараженных хостах группировка использует зарегистрированный на Сейшелах Windows-хост с RDP-подключением, арендованный у американского провайдера хостинга Nybula LLC, и группу DDNS-доменов.
196.251.66.118
myhost.servepics.com
myhost.misecure.com
kilimanjaro.theworkpc.com
Артефакты, обнаруженные экспертами PT ESC на инцидентах, позволили связать DarkGaboon с целой серией кибератак 2023–2025 годов на российские компании с использованием шифровальщика LockBit.
Подробности — в нашем блоге.
#TI #APT #Malware
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22❤9🆒5🏆4👍1
После третьей я сегодня... 🤌
Anonymous Poll
16%
Волчаро Детектино 🐺
6%
Коррелято Отключато 😐
3%
Патчело Апдейтини 😬
8%
Алертино Эскалато 🌚
6%
Секурито Аварнесито 😼
13%
Фолзито Закрывато 🙅♂️
11%
Детектини Пропустини 🙈
4%
Копилото Вызывато 📞
21%
Реверсило Малварило 👾
11%
Нагрузилини Упалини 🤦♀️
😁32🤡12👍9😎5💩2❤1
IoCs-детокс: защищаем TI от ложных индикаторов ✋
Представьте ситуацию: ваша команда SOC получает свежий фид с индикаторами компрометации. В списке — сотни новых IP-адресов, хешей и доменов. Вы загружаете их в свою систему защиты, и... начинается хаос. Ложные срабатывания сыплются, как из рога изобилия, легитимный трафик блокируется, а настоящие угрозы теряются в этом шуме🤯
Почему ложные индикаторы — это серьезная проблема? Сначала аналитики ИБ бурно реагируют на каждый новый индикатор. Но после десятков ложных срабатываний наступает «усталость от предупреждений» — и вот уже настоящая угроза проходит незамеченной. Кроме того, это формирует дурной имидж для фидов в целом, т. к. аналитики начинают считать, что от них больше вреда, чем пользы.
🤔 Откуда берутся ложные индикаторов?
• Ошибки аналитиков. Человеческий фактор никто не отменял. Опечатка в отчете может превратить легитимный IP-адрес во вредоносный.
• Устаревшие данные. Индикатор мог быть актуальным год назад, но сейчас принадлежит совершенно безобидному сервису.
• Поспешные выводы. Некоторые исследователи раздувают свои отчеты, добавляя непроверенные данные.
• Контекстные ошибки. IP-адрес может считаться зловредным в одной кампании, но совершенно нормальным в контексте другой активности.
• Имитовставки. Некоторые злоумышленники специально «подбрасывают» ложные индикаторы, чтобы замаскировать реальную вредоносную активность и дискредитировать конкретных TI-провайдеров.
😎 Как защититься от ложных индикаторов?
1️⃣ Лучше всего не доверять одному единственному источнику. Сверяйте каждый подозрительный индикатор минимум с тремя-четырьмя авторитетными базами угроз или фидами от других TI-провайдеров.
2️⃣ Доверяйте только проверенным поставщикам TI-данных с хорошей репутацией. Здесь особенно поможет внедрение системы оценки качества TI-поставщиков, про которую мы говорили ранее.
3️⃣ Прежде чем предпринимать какие-либо действия по событиям безопасности, связанным с индикатором компрометации, его контекст можно подвергнуть дополнительному анализу. Например, если контекст пустой, а есть просто указание, что индикатор вредоносный, то его лучше либо отфильтровать, либо поставить на мониторинг. Если же есть явные связи с деятельностью группировки, используемые техники и связи с другими опасными индикаторами, то такую активность можно заблокировать.
4️⃣ Новую итерацию фидов или пачку новых индикаторов сначала желательно рассматривать только в режиме мониторинга хотя бы в течение нескольких часов. Понаблюдайте за их активностью, прежде чем вносить в блокирующие правила.
5️⃣ Для блокирующих правил на основе индикаторов компрометации можно рассмотреть проверку наличия событий безопасности от других типов СЗИ.
Киберпреступники прекрасно знают о проблеме ложных IoC и активно этим пользуются. Грамотная фильтрация индикаторов — это не просто удобство, а необходимость для эффективной защиты.
#TI #ioc #tips
@ptescalator
Представьте ситуацию: ваша команда SOC получает свежий фид с индикаторами компрометации. В списке — сотни новых IP-адресов, хешей и доменов. Вы загружаете их в свою систему защиты, и... начинается хаос. Ложные срабатывания сыплются, как из рога изобилия, легитимный трафик блокируется, а настоящие угрозы теряются в этом шуме
Почему ложные индикаторы — это серьезная проблема? Сначала аналитики ИБ бурно реагируют на каждый новый индикатор. Но после десятков ложных срабатываний наступает «усталость от предупреждений» — и вот уже настоящая угроза проходит незамеченной. Кроме того, это формирует дурной имидж для фидов в целом, т. к. аналитики начинают считать, что от них больше вреда, чем пользы.
• Ошибки аналитиков. Человеческий фактор никто не отменял. Опечатка в отчете может превратить легитимный IP-адрес во вредоносный.
• Устаревшие данные. Индикатор мог быть актуальным год назад, но сейчас принадлежит совершенно безобидному сервису.
• Поспешные выводы. Некоторые исследователи раздувают свои отчеты, добавляя непроверенные данные.
• Контекстные ошибки. IP-адрес может считаться зловредным в одной кампании, но совершенно нормальным в контексте другой активности.
• Имитовставки. Некоторые злоумышленники специально «подбрасывают» ложные индикаторы, чтобы замаскировать реальную вредоносную активность и дискредитировать конкретных TI-провайдеров.
Киберпреступники прекрасно знают о проблеме ложных IoC и активно этим пользуются. Грамотная фильтрация индикаторов — это не просто удобство, а необходимость для эффективной защиты.
#TI #ioc #tips
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22👌8👍5👎4❤2🆒2💯1
Мутация Exchange. Как мы аномалии в Outlook-страницах ловили 😮
В продолжение историй с расследований инцидентов (о них можно почитать вот тут, здесь и частично послушать тут) мы решили проанализировать общую концепцию вставок вредоносного кода в страницы аутентификации Microsoft Outlook. В итоге:
• Помимо обнаруженного на расследованиях инцидентов кейлоггера, обнаружили множество других аналогичных вредоносов.
• Ключевое отличие всех вредоносных фрагментов кода заключается в способе отправки учетных данных жертв: в нем применяются сохранение данных в файл на сервере, DNS-туннелирование, отправка сообщений в телеграм-бота и другие техники.
• Заражения были обнаружены в 26 странах. Большинство скомпрометированных серверов находятся во Вьетнаме, Китае, России, Тайване.
• Как показывает статистика, основная причина успешных атак на серверы — отсутствие установленных обновлений безопасности; на 3 из 65 серверов обновления отсутствовали с 2013 года.
📫 Какие кейлоггеры были обнаружены, куда и как хакеры отправляют данные жертв и как обнаружить вредоносный код в странице Outlook, рассказали в нашем исследовании.
#TI #IR #Malware
@ptescalator
В продолжение историй с расследований инцидентов (о них можно почитать вот тут, здесь и частично послушать тут) мы решили проанализировать общую концепцию вставок вредоносного кода в страницы аутентификации Microsoft Outlook. В итоге:
• Помимо обнаруженного на расследованиях инцидентов кейлоггера, обнаружили множество других аналогичных вредоносов.
• Ключевое отличие всех вредоносных фрагментов кода заключается в способе отправки учетных данных жертв: в нем применяются сохранение данных в файл на сервере, DNS-туннелирование, отправка сообщений в телеграм-бота и другие техники.
• Заражения были обнаружены в 26 странах. Большинство скомпрометированных серверов находятся во Вьетнаме, Китае, России, Тайване.
• Как показывает статистика, основная причина успешных атак на серверы — отсутствие установленных обновлений безопасности; на 3 из 65 серверов обновления отсутствовали с 2013 года.
📫 Какие кейлоггеры были обнаружены, куда и как хакеры отправляют данные жертв и как обнаружить вредоносный код в странице Outlook, рассказали в нашем исследовании.
#TI #IR #Malware
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21❤14👍10❤🔥2
По следам 1C_Shell. Расследуем атаки с помощью журнала регистрации 🐾
В одном из предыдущих постов мы писали об обнаружении атак на систему «1С», в которых злоумышленники использовали инструмент 1C_shell. Он представляет собой внешнюю обработку, позволяющую запустить произвольный код на сервере «1С:Предприятие».
Подобные атаки интересны тем, что оставляют мало очевидных следов в скомпрометированных системах. В частности, тяжело определить источник атаки, особенно в условиях ротации журналов событий Windows.
Одним из артефактов, которые могут нам помочь в расследовании, является журнал регистрации.
💡 Журнал регистрации — механизм в системе «1С», предназначенный для логирования действия пользователей, в том числе начала и завершения сессий.
Чтобы просмотреть журнал регистрации, перейдем в конфигуратор и на вкладке «Администрирование» выберем соответствующий пункт (скриншот 1).
В журнале, помимо всего прочего, мы можем увидеть события начала и завершения пользовательских сеансов (скриншот 2). Таким образом, зная временной промежуток, в рамках которого происходила вредоносная активность, мы определим подозрительные сессии. В рамках этих сессий злоумышленники могли выполнять команды.
Файлы журнала регистрации в случае клиент-серверного варианта информационной базы по умолчанию хранятся в рабочей папке кластера:
Логи имеют необычный формат и плохо пригодны для ручного анализа. О формате можно почитать в статье «Инфостарт»: описание актуально для «1С:Предприятия» версий 8.1 и 8.2, но с тех пор формат изменился незначительно.
💡 Актуальная структура журнала регистрации описана в Руководстве администратора «1С:Предприятия» — однако доступ к документу ограничен.
Для того чтобы распарсить файлы журнала регистрации, можно воспользоваться встроенной консольной утилитой ibcmd, предназначенной для администрирования сервера «1С». Она входит в комплект, поставляемый при установке «1С:Предприятия», и, начиная с версии 8.3.25, имеет функциональность для обработки файлов журнала регистрации.
Утилита расположена в папке
Документацию утилиты также можно найти в Руководстве администратора.
Для того чтобы распарсить журнал регистрации и на выходе получить файл формата JSONL, можно использовать следующую команду:
Пример выходной строки:
#ir #detect #dfir #malware
@ptescalator
В одном из предыдущих постов мы писали об обнаружении атак на систему «1С», в которых злоумышленники использовали инструмент 1C_shell. Он представляет собой внешнюю обработку, позволяющую запустить произвольный код на сервере «1С:Предприятие».
Подобные атаки интересны тем, что оставляют мало очевидных следов в скомпрометированных системах. В частности, тяжело определить источник атаки, особенно в условиях ротации журналов событий Windows.
Одним из артефактов, которые могут нам помочь в расследовании, является журнал регистрации.
Чтобы просмотреть журнал регистрации, перейдем в конфигуратор и на вкладке «Администрирование» выберем соответствующий пункт (скриншот 1).
В журнале, помимо всего прочего, мы можем увидеть события начала и завершения пользовательских сеансов (скриншот 2). Таким образом, зная временной промежуток, в рамках которого происходила вредоносная активность, мы определим подозрительные сессии. В рамках этих сессий злоумышленники могли выполнять команды.
Файлы журнала регистрации в случае клиент-серверного варианта информационной базы по умолчанию хранятся в рабочей папке кластера:
C:\Program Files\1cv8\srvinfo\reg_****\****\1Cv8Log
Логи имеют необычный формат и плохо пригодны для ручного анализа. О формате можно почитать в статье «Инфостарт»: описание актуально для «1С:Предприятия» версий 8.1 и 8.2, но с тех пор формат изменился незначительно.
💡 Актуальная структура журнала регистрации описана в Руководстве администратора «1С:Предприятия» — однако доступ к документу ограничен.
Для того чтобы распарсить файлы журнала регистрации, можно воспользоваться встроенной консольной утилитой ibcmd, предназначенной для администрирования сервера «1С». Она входит в комплект, поставляемый при установке «1С:Предприятия», и, начиная с версии 8.3.25, имеет функциональность для обработки файлов журнала регистрации.
Утилита расположена в папке
C:\Program Files\1cv8\<version>\bin. Папку можно скопировать и использовать на другом компьютере без необходимости устанавливать систему «1С».Документацию утилиты также можно найти в Руководстве администратора.
Для того чтобы распарсить журнал регистрации и на выходе получить файл формата JSONL, можно использовать следующую команду:
ibcmd.exe eventlog export -f json --skip-root -o C:\<output_path> \output.jsonl C:\<path_to_1Cv8Log>
Пример выходной строки:
{"ApplicationName":"1CV8C","ApplicationPresentation":"Тонкий клиент","Comment":"","Computer":"DESKTOP-QBF9N0A","Connection":"25","Data":null,"DataPresentation":"","Date":"2025-06-02T17:38:31","Event":"_$Session$_.Start","EventPresentation":"Сеанс. Начало","Level":"Information","Metadata":"00000000-0000-0000-0000-000000000000","MetadataPresentation":"<Не определено 00000000-0000-0000-0000-000000000000>","Port":"1560","ServerName":"WIN-UB4CFT0Q9FN","Session":"1","SessionDataSeparation":null,"SessionDataSeparationPresentation":null,"SyncPort":"0","TransactionID":"","TransactionStatus":"NotApplicable","User":"071523a4-516f-4fce-ba4b-0d11ab7a1893","UserName":""}
{"ApplicationName":"1CV8C","ApplicationPresentation":"Тонкий клиент","Comment":"","Computer":"DESKTOP-QBF9N0A","Connection":"0","Data":null,"DataPresentation":"","Date":"2025-06-02T17:38:57","Event":"_$Session$_.Finish","EventPresentation":"Сеанс. Завершение","Level":"Information","Metadata":"00000000-0000-0000-0000-000000000000","MetadataPresentation":"<Не определено 00000000-0000-0000-0000-000000000000>","Port":"0","ServerName":"","Session":"1","SessionDataSeparation":null,"SessionDataSeparationPresentation":null,"SyncPort":"0","TransactionID":"","TransactionStatus":"NotApplicable","User":"071523a4-516f-4fce-ba4b-0d11ab7a1893","UserName":""}
#ir #detect #dfir #malware
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥30❤13✍8😁3👍2
В дополнение к предыдущему посту хотим рассказать о некоторых других потенциальных способах детектирования выполнения вредоносного кода в системе «1С» 😳
• Во-первых, если информационная база опубликована на веб-сервере, злоумышленники могут получить к ней доступ и запустить шелл через веб-клиент (скриншот 1).
В таком случае мы можем найти в логах IIS полезную информацию, в частности — обращение к информационной базе и загрузку внешней обработки:
После декодирования URL запроса выше мы получим строку, которая говорит о взаимодействии с внешней обработкой:
• Другой способ обнаружить следы вредоносной активности — проанализировать процесс
Стоит отметить, что этот метод не принесет результата, если сервер или процесс
#ir #detect #dfir #malware
@ptescalator
• Во-первых, если информационная база опубликована на веб-сервере, злоумышленники могут получить к ней доступ и запустить шелл через веб-клиент (скриншот 1).
В таком случае мы можем найти в логах IIS полезную информацию, в частности — обращение к информационной базе и загрузку внешней обработки:
2025-06-17 13:15:20 192.168.80.130 GET /mybase/ - 80 - 192.168.80.129 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/137.0.0.0+Safari/537.36+Edg/137.0.0.0 - 200 0 0 2
2025-06-17 13:18:55 192.168.80.130 GET /mybase/ru/e1cib/logForm cmd=elements&formId=urn:form:ext:0:ce244e8a-6d30-4e49-a244-c6d80d2ea085@n=%22%D0%92%D0%BD%D0%B5%D1%88%D0%BD%D1%8F%D1%8F%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0.%D0%92%D0%BD%D0%B5%D1%88%D0%BD%D1%8F%D1%8F%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B01%22;v=%223bb1cd7e449b0540951594ef9f12fb6d00000000%22&altFormId=urn:form:ext:8:add30da0-7627-464c-b936-820f49ac3e75@n=%22%D0%92%D0%BD%D0%B5%D1%88%D0%BD%D1%8F%D1%8F%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0.%D0%92%D0%BD%D0%B5%D1%88%D0%BD%D1%8F%D1%8F%D0%9E%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B01%22;v=%223bb1cd7e449b0540951594ef9f12fb6d00000000%22&sysver=8.3.18.1208&confver=3bb1cd7e449b0540951594ef9f12fb6d00000000&rolesId=0&clang=ru 80 - 192.168.80.129 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/137.0.0.0+Safari/537.36+Edg/137.0.0.0 https://192.168.80.130/mybase/ru/ 200 0 0 37
После декодирования URL запроса выше мы получим строку, которая говорит о взаимодействии с внешней обработкой:
"ВнешняяОбработка.ВнешняяОбработка1";v="3bb1cd7e449b0540951594ef9f12fb6d00000000"• Другой способ обнаружить следы вредоносной активности — проанализировать процесс
rphost.exe. В случае выполнения кода через 1C_shell в памяти процесса остаются фрагменты кода внешней обработки (скриншот 2).Стоит отметить, что этот метод не принесет результата, если сервер или процесс
rphost.exe будут перезапущены после выполнения вредоносного кода.#ir #detect #dfir #malware
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12👍7🤝7✍3🔥3🙏1
Когда я увидел инфу про утечку 16 млрд логинов и паролей...
Anonymous Poll
28%
Не поверил 😑
3%
Написал пост ✏️
8%
Поменял пароль 🔄
12%
Начал искать свободное место на диске 👨💻
12%
Придерживался какой-то тактики 🧐
6%
Нашел там свой забытый пароль 😉
1%
Пошел комментировать в СМИ 🎤
5%
Сходил в личку к Лукацкому 👋
8%
Отписался от Forbes 🙅♀️
17%
Какая утечка?❔
😁16👍7❤4😱3
Reflection Relay. Никогда такого не было, и вот опять (CVE-2025-33073) 😐
Одной из самых популярных техник для повышения привилегий в домене Active Directory является Relay. Долгое время всем были хорошо известны атаки NTLM Relay, но не так давно было описано несколько техник, позволяющих выполнить Relay с использованием Kerberos. Многим будет понятнее, о чем речь, если сказать SMB Relay или ADCS ESC8. Но техник для Relay-атак гораздо больше, выполнять их можно на HTTP, SMB, RPC, MSSQL, WinRMS, LDAP и, вероятно, еще на какие-то протоколы, которые будут описаны в будущем.
Если Relay-атакам подвержены NTLM и Kerberos в связке с различными протоколами, то как защититься от них? На самом деле существуют встроенные механизмы защиты, которые просто нужно отладить. Подробнее о каждом из них поговорим в следующих постах. Но сегодня хочется акцентировать внимание на недавно обнаруженной уязвимости — CVE-2025-33073.
❗️ Сначала немного о самой уязвимости. Эксплуатация проходит в связке с Relay-атакой — хоть Kerberos, хоть NTLM. Корни ее уходят в далекий 2008 год. В том году Microsoft выпустила бюллетень по безопасности MS08-068, после которого перестала работать техника Relay, когда компьютер атаковал бы сам себя.
В то время еще не были широко известны техники типа Coerce, но ярлычками уже активно пользовались (например, LNK-файлами, которые хакеры разбрасывали в доступных для записи общих папках SMB) для получения сессии администратора на устройстве и выполнения Relay-атаки на него же для повышения привилегий. Такой Relay будем называть Reflective.
С тех пор появились техники принуждения к аутентификации — Coerce- и сами Relay-атаки стали более изощренными, но Reflective Relay именно через сеть не было. Но вот наступает 2021 год, и в сети появляется исследование, в котором достаточно подробно описывается механизм Kerberos-аутентификации, в том числе на SMB-сервере. Нет смысла повторятся, стоит лишь сказать, что там впервые фигурирует странное хостовое имя:
Кроме того, автор справедливо замечает, что строка подобного вида вполне может быть DNS-записью. Несмотря на фундаментальность исследования, уязвимостей в механизме найдено не было.
🗓 Вот наступает 2025 год, и 11 июня выходит два исследования подряд: первое и второе. Они тесно связаны друг с другом и основаны на ресерче 2021 года, поэтому читать их лучше именно в таком порядке. В этих исследованиях демонстрируется возможность Reflective Relay как NTLM, так и Kerberos.
Про эксплуатацию CVE-2025-33073 в посте ниже👇
#cve #win #offensive
@ptescalator
Одной из самых популярных техник для повышения привилегий в домене Active Directory является Relay. Долгое время всем были хорошо известны атаки NTLM Relay, но не так давно было описано несколько техник, позволяющих выполнить Relay с использованием Kerberos. Многим будет понятнее, о чем речь, если сказать SMB Relay или ADCS ESC8. Но техник для Relay-атак гораздо больше, выполнять их можно на HTTP, SMB, RPC, MSSQL, WinRMS, LDAP и, вероятно, еще на какие-то протоколы, которые будут описаны в будущем.
Если Relay-атакам подвержены NTLM и Kerberos в связке с различными протоколами, то как защититься от них? На самом деле существуют встроенные механизмы защиты, которые просто нужно отладить. Подробнее о каждом из них поговорим в следующих постах. Но сегодня хочется акцентировать внимание на недавно обнаруженной уязвимости — CVE-2025-33073.
В то время еще не были широко известны техники типа Coerce, но ярлычками уже активно пользовались (например, LNK-файлами, которые хакеры разбрасывали в доступных для записи общих папках SMB) для получения сессии администратора на устройстве и выполнения Relay-атаки на него же для повышения привилегий. Такой Relay будем называть Reflective.
С тех пор появились техники принуждения к аутентификации — Coerce- и сами Relay-атаки стали более изощренными, но Reflective Relay именно через сеть не было. Но вот наступает 2021 год, и в сети появляется исследование, в котором достаточно подробно описывается механизм Kerberos-аутентификации, в том числе на SMB-сервере. Нет смысла повторятся, стоит лишь сказать, что там впервые фигурирует странное хостовое имя:
fileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAA
Кроме того, автор справедливо замечает, что строка подобного вида вполне может быть DNS-записью. Несмотря на фундаментальность исследования, уязвимостей в механизме найдено не было.
🗓 Вот наступает 2025 год, и 11 июня выходит два исследования подряд: первое и второе. Они тесно связаны друг с другом и основаны на ресерче 2021 года, поэтому читать их лучше именно в таком порядке. В этих исследованиях демонстрируется возможность Reflective Relay как NTLM, так и Kerberos.
Про эксплуатацию CVE-2025-33073 в посте ниже👇
#cve #win #offensive
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17👍8❤7👏2
• Учетная запись в домене с самыми рядовыми привилегиями.
• На атакуемом устройстве не настроено принудительное требование подписи SMB.
• На атакуемом устройстве не стоит патч, устраняющий уязвимость CVE-2025-33073, который был выпущен в июне 2025 года.
И дополнительно одно из двух:
• Либо возможность регистрации DNS-записи в домене (по умолчанию могут все пользователи домена).
• Либо нахождение в одной широковещательной сети с атакуемым устройством (проведение атаки NBNS, LLMNR и mDNS-спуфинга).
Рассмотрим два варианта эксплуатации с дампом локальных учетных данных из
SAM и SECURITY. 1. Атакующий регистрирует DNS-запись формата
localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA2. Атакующий выполняет Coerce-атаку на устройство без SMB Signing.
3. Устройство разрешает имя по DNS, в котором получает IP-адрес атакующего.
4. Устройство проходит аутентификацию на сервере атакующего.
5. Атакующий выполняет Relay-атаку на это же устройство, получает аутентифицированную сессию с правами SYSTEM.
1. Атакующий запускает спуфинг с ответом на имя хоста
localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA2. Атакующий выполняет Coerce-атаку на устройство в локальной сети.
3. Устройство пытается разрешить имя по DNS, не находит его и переходит к многоадресным протоколам.
4. Атакующий сообщает устройству, что имя принадлежит ему.
5. Устройство проходит аутентификацию на сервере атакующего.
6. Атакующий выполняет Relay-атаку на это же устройство, получает аутентифицированную сессию с правами SYSTEM.
Вместо вывода хочется подчеркнуть, что эта уязвимость стала результатом многолетних исследований нескольких специалистов и, вероятно, кем-то она могла быть обнаружена и использована ранее. Никто не знает, сколько еще таких уязвимостей будет обнаружено. Но в этом случае, как и в большинстве других, применив лучшие практики по защите заранее, можно избежать серьезных последствий при появлении подобных уязвимостей даже без установки обновления.
Рекомендации по защите от уязвимости:
• Установите обновления безопасности от 10 июня 2025 года.
• Настройте принудительное требование подписи SMB для SMB-служб контроллеров и рабочих станций.
В следующих постах расскажем, как детектить уязвимость
#cve #win #offensive
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥25👍15👏9❤7
В продолжение предыдущих публикаций рассказываем, как обнаруживать уязвимость CVE-2025-33073 🕵️♂️
1️⃣ Отслеживать DNS-запросы с Marshalled-суффиксом
В атаках Reflection Relay злоумышленник вынуждает службы выполнять DNS-запросы к поддельным именам с паттерном
• Что мониторить
Все DNS-запросы, где имя узла заканчивается на marshalled-часть (
• События
Sysmon Event ID 22 (DNS-запросы на узлах).
События DNS-серверов, содержащие такие запросы.
2️⃣ Ловить LDAP-поиск с marshalled-суффиксом
Reflection Relay вызывает LDAP-запросы от атакуемого узла к контроллеру домена, в которых параметр
• Что мониторить:
Запросы LDAP, в которых параметр
• События:
Windows Security Event 1644 ("A search was performed in Active Directory") на контроллерах домена.
3️⃣ Знать механику CVE-2025-33073 и Coerce-атаки
Как работает уязвимость:
• Coerce-атаки (PetitPotam, PrinterBug) вынуждают жертву подключиться к поддельному DNS-имени.
• Windows ошибочно считает запрос локальным из-за marshalled-суффикса, отключая проверки NTLM и Kerberos.
• Это позволяет атакующему выполнить Relay сессии обратно на жертву для получения RCE с правами SYSTEM.
Примеры Coerce-атак:
• PetitPotam: принуждение через уязвимость в EFS RPC, заставляющее LSASS инициировать аутентификацию;
• PrinterBug: принудительная отправка NTLM-хешей через уязвимость в службе печати Windows (MS-RPRN).
4️⃣ Опираться на примеры сработавших правил корреляции
При реализации CVE-2025-33073 совместно с PetitPotam для дампа учетных данных сработали следующие правила корреляции:
• Coerce_Auth: правило обнаруживает Coerce-атаки на узел с целью перехвата хеша машинной учетной записи атакованного узла, а также пытается определить по названию используемого пайпа, какая техника атаки используется (netdfs = DFSCoerce; spoolss = PrinterBug; fssagentrpc = ShadowCoerce; efsrpc, lsarpc, samr, lsass, netlogon = PetitPotam; msftewds = WSPCoerce) и какой инструмент применяется.
• SVCCTL_Connection: правило обнаруживает подключение к именованному каналу
• Remote_Password_Dump: правило обнаруживает удаленный дамп паролей через обращение к именованному каналу
5️⃣ Использовать примеры SIGMA-правил
Если у вас нет MaxPatrol SIEM, то вот вам пример простых SIGMA-правил:
Для Sysmon Event ID 22.
Для Windows Security Event 1644.
6️⃣ Использовать наши публичные Suricata-сигнатуры для обнаружения этой атаки
#detect #cve #win #sigma #rules
@ptescalator
1️⃣ Отслеживать DNS-запросы с Marshalled-суффиксом
В атаках Reflection Relay злоумышленник вынуждает службы выполнять DNS-запросы к поддельным именам с паттерном
1UWhRCA + 37–45 символов Base64. Записи вида srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA.example.com или localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA.example.com — индикаторы попытки Reflection Relay (NTLM, Kerberos).• Что мониторить
Все DNS-запросы, где имя узла заканчивается на marshalled-часть (
1UWhRCA + 37-45 символов Base64).• События
Sysmon Event ID 22 (DNS-запросы на узлах).
События DNS-серверов, содержащие такие запросы.
2️⃣ Ловить LDAP-поиск с marshalled-суффиксом
Reflection Relay вызывает LDAP-запросы от атакуемого узла к контроллеру домена, в которых параметр
name= содержит поддельное DNS-имя формата [имя_узла]1UWhRCA[Base64]. Это происходит при выполнении Relay-атаки обратно на жертву.• Что мониторить:
Запросы LDAP, в которых параметр
name= содержит конструкцию: "[имя_хоста]1UWhRCA[символы Base64]"• События:
Windows Security Event 1644 ("A search was performed in Active Directory") на контроллерах домена.
3️⃣ Знать механику CVE-2025-33073 и Coerce-атаки
Как работает уязвимость:
• Coerce-атаки (PetitPotam, PrinterBug) вынуждают жертву подключиться к поддельному DNS-имени.
• Windows ошибочно считает запрос локальным из-за marshalled-суффикса, отключая проверки NTLM и Kerberos.
• Это позволяет атакующему выполнить Relay сессии обратно на жертву для получения RCE с правами SYSTEM.
Примеры Coerce-атак:
• PetitPotam: принуждение через уязвимость в EFS RPC, заставляющее LSASS инициировать аутентификацию;
• PrinterBug: принудительная отправка NTLM-хешей через уязвимость в службе печати Windows (MS-RPRN).
4️⃣ Опираться на примеры сработавших правил корреляции
При реализации CVE-2025-33073 совместно с PetitPotam для дампа учетных данных сработали следующие правила корреляции:
• Coerce_Auth: правило обнаруживает Coerce-атаки на узел с целью перехвата хеша машинной учетной записи атакованного узла, а также пытается определить по названию используемого пайпа, какая техника атаки используется (netdfs = DFSCoerce; spoolss = PrinterBug; fssagentrpc = ShadowCoerce; efsrpc, lsarpc, samr, lsass, netlogon = PetitPotam; msftewds = WSPCoerce) и какой инструмент применяется.
• SVCCTL_Connection: правило обнаруживает подключение к именованному каналу
svcctl, который ответственен за удаленное конфигурирование служб Windows на узлах через Service Control Manager, что может привести к выполнению произвольного кода;• Remote_Password_Dump: правило обнаруживает удаленный дамп паролей через обращение к именованному каналу
WINREG.5️⃣ Использовать примеры SIGMA-правил
Если у вас нет MaxPatrol SIEM, то вот вам пример простых SIGMA-правил:
Для Sysmon Event ID 22.
Для Windows Security Event 1644.
6️⃣ Использовать наши публичные Suricata-сигнатуры для обнаружения этой атаки
#detect #cve #win #sigma #rules
@ptescalator
🔥21👍10❤9👏1
Во всемирный день рыболовства самое время спросить... Как часто вы получаете фишинг на почту? 🎣
Anonymous Poll
12%
Каждый раз, когда вижу руководителя в отправителях 😎
14%
Скучаю по нигерийским принцессам 👸🏿
2%
Больше, чем спама от рассылок 🛍
2%
Я точно в CRM у хакеров 👨💻
12%
Чаще, чем посты в ESCalator 😔
3%
На завтрак, обед и ужин 🍽
4%
Два раза в месяц от банка 💸
12%
Хотя бы они мне пишут... 🤝
23%
Отписался от фишинга 🙅
16%
Я и сам своего рода рыбак 😏
😁13👍4👏3👀2🤡1🗿1
А у нас большое событие! 😡
В PT ESC открылась Антивирусная лаборатория: мы объединили экспертизу «ВИРУСБЛОКАДА» с нашей, анализируем множество сэмплов и самостоятельно пишем сигнатуры для антивирусной базы.
🌚 Более того, на днях эксперт Позитива впервые создал детектирующую запись для антивирусного движка. А перед этим освоил теорию и практику новой для нас технологии и навык использования необходимого набора инструментов. Сможете угадать название детекта? Голосуйте в опросе ниже.
Если у вас есть интересный вредонос, который надо проанализировать и для которого необходимо создать правила обнаружения в наших продуктах, то не стесняйтесь: [email protected]
#avlab
@ptescalator
В PT ESC открылась Антивирусная лаборатория: мы объединили экспертизу «ВИРУСБЛОКАДА» с нашей, анализируем множество сэмплов и самостоятельно пишем сигнатуры для антивирусной базы.
Если у вас есть интересный вредонос, который надо проанализировать и для которого необходимо создать правила обнаружения в наших продуктах, то не стесняйтесь: [email protected]
#avlab
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16🤯13🔥11❤4👎2😁2