e014dadf6d93b312b93e2fc857791c241692da4015da7a24a4d42a946551add2

Наше внимание привлекло сообщение от аккаунта, с которого залили данный сэмпл:

Хм, ICS-вредонос, причем уже с готовым названием S7Flip (то есть нам даже не нужно напрягать свою фантазию, чтобы назвать его)? Звучит интересно! Давайте взглянем, что там внутри.

После закрепления в автозапуске под названием aphp.exe сэмпл начинает собирать адреса устройств в локальной сети — это адреса 192.168.*.*, 10.*.*.* и 172.*.*.*, после чего проверяет на них наличие определенных открытых портов, которые широко используются промышленными устройствами:

• 102 — в основном используют контроллеры Siemens для взаимодействия по протоколу S7Comm или S7Comm+.
• 502 — стандартный порт протокола Modbus TCP; его могут использовать устройства любых производителей.
• 44818 — в основном используют контроллеры Allen-Bradley (Rockwell) для взаимодействия по протоколу EtherNet/IP (CIP).

Подключение к устройствам Allen-Bradley (Rockwell) фактически не работает. Реализация клиента для EtherNet/IP (CIP) отсутствует: ветка переиспользует Siemens-клиент и пытается подключиться по порту 102 как к контроллеру Siemens. С настоящим Allen-Bradley соединение не установится — воздействие на устройства, открывшие только порт 44818, не оказывается вовсе.

Определив нужные устройства, S7Flip подключается к ним и начинает применять один из деструктивных механизмов (или сразу оба).

Механизм 1: «randomize» значений

По S7Comm (порт 102): по очереди обходит блоки DB 1–10; для каждого выбирает случайное смещение 0–99, читает оттуда 4-байтовое целое, прибавляет случайное целое число от −10 до +10 и записывает обратно.

По Modbus TCP (порт 502): выбирает 16-битный holding-регистр по случайному адресу 0–99, читает текущее значение, прибавляет случайное целое число от −10 до +10 и записывает обратно.

Механизм 2: инверсия битов (findAndModifyInputs)

По S7Comm (порт 102): последовательно проходит первые 100 байтов в блоках DB 1–10: читает байт, меняет его младший бит на противоположный и записывает обратно.

По Modbus TCP (порт 502): последовательно проходит однобитовые ячейки записи (coils — дискретные выводы, команды, флаги) в диапазоне 0–255: читает бит, меняет на противоположный и записывает обратно.

Каждое изменение пишется в logs.csv рядом с исполняемым файлом и содержит пять колонок — время, тег, вендор, старое и новое значение.

Помимо данного бинаря, мы также нашли еще один:

88717716e54b35682a28d673764975d439a31ee194c85dfc619a15ea93ab1280

По логике работы он ничем не отличается от рассмотренного ранее образца. Главное отличие заключается в том, что библиотека libmodbus, реализующая работу протокола Modbus, в e014dadf6d93b312b93e2fc857791c241692da4015da7a24a4d42a946551add2 динамически слинкована, а в 88717716e54b35682a28d673764975d439a31ee194c85dfc619a15ea93ab1280 — статически.

В этот же день с этого же аккаунта jeans, помимо e014dadf6d93b312b93e2fc857791c241692da4015da7a24a4d42a946551add2 (название файла — Edge.exe), был залит еще один бинарь:

2c57c1a39933514c63b5a7b585f5948ead04b65e4df96fb595ccda84208c4aa0

При ближайшем рассмотрении он оказался вайпером. При запуске он по-джентльменски спрашивает, не хотите ли вы установить Microsoft Edge:

И если вы отказываетесь, то вайпер прекращает свою работу 😅

Но вот если вы соглашаетесь… то будьте готовы к «непредвиденным обстоятельствам». Вот их список:

• рекурсивное удаление всего содержимого папки %USERPROFILE%\Desktop;
• там же будет создан файл compiled-desktop, который будет содержать ровно 1 048 576 случайных байт;
• ну и, разумеется, файл README.txt с вежливой просьбой перевести биткоины в размере 100 долларов.

После всего этого вредонос добавляет себя в автозапуск.

Расшифровка файлов не предусмотрена: содержимое рабочего стола нигде не сохраняется. Это псевдовымогатель-вайпер.

Самое интересное, что в README.txt указан кошелек, на который злоумышленники предлагают переслать деньги: bc1qp6ejw8ptj9l9pkscmlf8fhhkrrjeawgpyjvtq8 — это официальный кошелек для донатов проекта Bitcoin.org. Т. е. жулики на самом деле не хотят выкупа? Хм, интересно… 🤑

Чуть позже jeans залил еще один вариант данного инструмента — f47502628708300840efe2771a3c5e7e9a631205512f0a2ee6382a00a92056e2, причем на этот раз файл называется не Edge.exe, а Edgev5.exe.

Обозначает ли v5 какое-то развитие или дальнейшее улучшение вредоноса? Да, в новой версии автор добавил симметричное шифрование файлов с помощью AES-256-GCM, а также расширил количество папок для шифрования: теперь помимо Desktop шифрованию подлежат Downloads и Documents. Правда, есть один нюанс… ключ для расшифрования данных находится в файле master_key.dat, да и биткоин-кошелек такой же, как и в более ранней версии вайпера.

По всей видимости, автор вредоноса активно развивает и тестирует свой инструмент. Возможно, в будущем он начнет активно применять его в «боевом» виде.

А какая связь между S7Flip и вайперами? 🧐

В ходе чтения данного поста у вас, возможно, возник вопрос: «а как связаны S7Flip и вайпер между собой?» И на самом деле определенные совпадения есть:

• все бинари были собраны с помощью тулчейна GCC 16.2.0;
• timestamp сборки PE-файлов 88717716e54b35682a28d673769475d439a31ee194c85dfc619a15ea93ab1280 (S7Flip) и 2c57c1a39933514c63b5a7b585f5948ead04b65e4df96fb595ccda84208c4aa0 (Edge.exe) совпадает с точностью до дня — 2026-09-13;
• общий аккаунт, с которого файлы были залиты на MalwareBazaar, — jeans.

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

IoCs

#malware #win #ioc
@ptescalator

Установив его, мы обнаружили, что при запуске пользователя встречает интерфейс известной программы для управления звонками на Android — Right Dialer от разработчика Goodwy.

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

Открыв AndroidManifest.xml, нетрудно увидеть, что основной пакет — com.syscore.toolsuite, а не com.goodwy.dialer. Это означает, что код Goodwy был встроен в чужое приложение — уже известный Android-шпион LunaSpy, более ранняя версия которого была рассмотрена в статье.

Перед статическим исследованием образца мы запустили его в песочнице PT Sandbox, чтобы получить общее представление о работе ВПО:

Ключевые наблюдения из динамического анализа:

• Коммуникация с управляющими серверами
• Получение привилегий
• Создание скрытых файлов

Злоумышленники расширили свой шпион рядом новых команд (как говорится, если используешь Accessibility Service, то используй его по полной):

• GET_CALL_RECORDINGS — отправляет на управляющий сервер список имен файлов, перебирая файлы с расширением .wav, чей размер больше 44 байтов (размер заголовка WAV), в директории getFilesDir()/call_recordings
• DOWNLOAD_CALL_RECORDING — отправляет на управляющий сервер запись звонка с указанным id, закодированную в Base64
• SET_REDIRECT_RULES, GET_REDIRECT_RULES — подмена исходящих звонков согласно полученным с управляющего сервера правилам
• Добавилось больше команд для управления логированием устройства: REQUEST_LOGS, CLEAR_LOGS, LOGGING_ENABLE, LOGGING_DISABLE
• RESET_SOFT, RESET_DEEP, RESET_GLOBAL — перезапуск части или всех вспомогательных сервисов шпиона
• RESET_REBOOT — имитация перезагрузки устройства (при получении — останавливает свои сервисы, отменяет задачи WorkManager, имитирует задержку при загрузке системы (8 секунд), после чего перезапускает сервисы)
• GET_SCREEN_TREE — получить параметры текущего экрана: width, height, объекты на экране, их позиции, текст и свойства
• Сложные команды с параметрами для управления устройством (имитация действий пользователя): PERFORM_TAP (выполнить нажатие на экран), PERFORM_SWIPE (провести по экрану), PERFORM_INPUT_TEXT (выполнить вставку текста), PERFORM_PATH_GESTURE (выполнить жест по заданным позициям с определенной длительностью нажатия), PERFORM_PATTERN_UNLOCK (команда похожа на PERFORM_PATH_GESTURE, однако предназначена для адаптивных паттернов, например, разблокировка по рисунку), PERFORM_BACK (выполнить действие «назад»), PERFORM_HOME (выполнить переход на домашний экран), PERFORM_RECENTS (просмотреть список недавних приложений) — команды, активно использующие функции PerformGlobalAction и механизм GestureDescription
• REVIVE_PERMISSIONS — показывает пользователю уведомление поверх всех окон с целью получения прав android.permission.CAMERA и android.permission.RECORD_AUDIO
• DISABLE_PLAY_PROTECT — отключить глобальную настройку в Android (Settings.Global.PACKAGE_VERIFIER_ENABLE), которая управляет проверкой приложений перед их установкой

Кроме того, ряд строк (например, IP-адреса, названия некоторых команд) шифруется алгоритмом XOR для усложнения анализа.

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

Меры предосторожности:

• Не стоит скачивать приложения с открытым исходным кодом из неизвестных источников, так как их легко видоизменить. Лучше скачивать их из Google Play или брать последний релиз со страницы разработчика.
• Не предоставляйте приложениям разрешения, которые им не потребуются (особенно разрешения Accessibility Service).
• При подозрении на заражение ВПО проверьте список установленных приложений или воспользуйтесь средствами для отслеживания активности.

Файловые индикаторы

Сетевые индикаторы

#malware #android
@ptescalator

Вредоносные файлы с этими расширениями чаще всего встречаются в сетевом трафике компаний. Давайте базово разберемся, почему.

🖥 .exe — классическое расширение исполняемых файлов в Windows: двойной клик — и у вас запускается Fortnite (не осуждаем), браузер, ваш любимый мессенджер, установщик или любая другая программа. А может запуститься и Trojan или какой-нибудь другой вредонос.

Чаще всего вы даже не видите, что у файла именно такое расширение: по умолчанию в Windows включена функция «Скрывать расширения для зарегистрированных типов файлов», из-за чего видно только первую часть имени. И этим пользуются злоумышленники.

Например, они маскируют файл под что-нибудь безобидное: вместо zarplaty_sep_2026.pdf.exe вы увидите просто zarplaty_sep_2026.pdf. Подозрений не вызывает, а интерес пробуждает. Клац-клац — и бамц.

В общем, для самозащиты рекомендуем отключить эту функцию. Делается просто, зато вы всегда будете знать, на что именно кликаете.

📄 .docm и .xlsm — а это знакомые всем офисным работягам расширения документов Microsoft Office. Их часто перекидывают по электронной почте, чатам и флешкам, так что обычно они не вызывают подозрений.

Только что-то тут с последними буквами расширений не так — скажете вы, и будете правы. Вместо x в конце здесь стоит m, а это означает, что такие документы поддерживают макросы — небольшие программы на специальном языке VBA, которые могут выполнять действия внутри документа. Также могут попадаться расширения .dotm и .xltm — это шаблоны документов с поддержкой макросов.

И так же, как с .exe, эти расширения по умолчанию скрыты в наименовании файлов в Windows, поэтому вы просто видите иконку документа и его название.

Макросы — полезная штука, которая помогает автоматизировать рутинные действия в документах (с их помощью энтузиасты даже умудрились запустить DOOM прямо в Word).

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

Так вот, к чему мы это решили объяснить

1️⃣ Внимательно следите за тем, что именно вы запускаете и какие разрешения даете.

2️⃣ Наши эксперты с помощью песочницы PT Sandbox проанализировали вредоносную активность, выявленную PT NAD в сетевом трафике организаций с октября 2025 года по июль 2026 года. И как раз 29% опасных файлов оказались с расширением .exe, а 26% — с расширениями Microsoft Office.

3️⃣ Как вы понимаете, эти файлы — только верхушка айсберга из вредоносов. Ниже в сетях были обнаружены и потенциально опасные инструменты, которые выглядят легитимно, различные вариации архивов и более интересные находки.

О них — в полной версии исследования на нашем сайте.

#malware
@ptescalator

Список пакетов:

🌟 svg-fetcher

🌟 tradepilot

🌟 polytrade

🌟 polymarket-kit

🌟 react-svg-chunk

🌟 gamified-trading-system

🌟 font-huge

🌟 font-hub

🌟 mdb-vite

🌟 router-processor

🌟 route-processor

Код, по классике жанра, навайбкожен. На это указывают избыточные поясняющие комментарии:

Логика пакетов

🔗 Конкатенация URL C2 из нескольких констант.

🔗 Запрос следующего стейджа. Из занятного:

🌟Нагрузка версионируется и в коде называется token. Нам известны стейджи 106, 107, 108 и 116.

Итоговый URL: http://svganchordev.net/icons/<token>

🌟 Код передает в заголовках ключ bearrtoken (орфография сохранена, вероятно, автор имел в виду bearertoken) со значением logo.

Второй стейдж представлен сильно обфусцированным JS-кодом-однострочником:

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

Реализация качественная, с мультистейджами, спору нет. Но это все равно вредоносная активность, поэтому репортим пакеты админам NPM 🫥

В релизах с токенами 106 и 116 есть изюминка, а именно вшитые публичный и приватный ключи GitLab:

Мы не можем воспользоваться этими ключами: они относятся к приватному инстансу GitLab, развернутому в инфраструктуре злоумышленника.

Однако интересно, что кампания ведется на настолько серьезном уровне, что злоумышленнику потребовалось версионирование кода, хотя можно было бы использовать Git локально. Можно предположить, что в GitLab настроен CI/CD-пайплайн для обфускации кода и публикации стейджей.

Хотите автоматически проверять, попали ли эти и другие вредоносные пакеты в ваш контур? Вам сюда: фиды для безопасной разработки из PT Fusion.

#npm #scs

@ptescalator

Известно, что в ходе атак злоумышленники могут использовать туннелирование. Например, прокинуть обратный туннель со взломанного Windows-хоста в глубине сети организации, чтобы с его помощью легко подключиться интерактивно по RDP к этому же хосту.

Методы выявления такой активности также известны. Например, стоит обязательно обращать внимание на наличие в логах IP-адресов 127.0.0.1 или ::1 в качестве источника — именно с таких адресов в пределах атакованной системы могут устанавливаться подключения к целевым сервисам.

😳 Много лет специалисты, расследовавшие взломы, отмечали и описывали в отчетах, что когда в подобных атаках для туннеля использовался ngrok, при подключении по RDP в логах вместо IP-адреса источника заносилось странное значение — ::%16777216.

С одной стороны, это отличный артефакт, который легко искать: он вряд ли встречается в нормальной активности и поэтому его наличие служит хорошим и довольно точным индикатором атаки.

Но, с другой стороны, нигде не было понятного объяснения, что это за «магическое число», почему именно оно возникает в логах и всегда ли это признак использования именно ngrok.

😎 Мы решили разобраться, и нам удалось получить ответы:

🔴 ::%16777216 появляется в логах в событии 1149 (а еще 4778 и 4779) вместо IP-адреса ::1 в результате ошибки в Windows.

🔴 Ошибка не связана с наличием какой-либо уязвимости, а вызвана несогласованной интерпретацией данных в памяти разными модулями протокола RDP

🔴 Ошибка возникает не только с адресом ::1, но и в любом другом случае, когда происходит подключение к RDP с использованием протокола IPv6 (например, вместо адреса fe80::6e1d:980d:9401:719b вы увидите в логах строку 0:0:fe80::6e1d:980d%2607874452)

🔴 Проблема чаще всего связывалась с утилитой ngrok, так как в ходе туннелирования она создает подключение на узле с использованием IPv6 по умолчанию, в отличие от многих других утилит, которые используют IPv4.

🔴 Адрес в логах «портится» не безвозвратно, его можно восстановить:

1. Взять значение из лога: 0:0:fe80::6e1d:980d%2607874452

2. Часть после % перевести в HEX: 2607874452 dec = 9b710194 hex

3. Убрать слева два нуля, дописать справа полученные цифры с учетом обратного порядка байт: fe80::6e1d:980d:9401:719b

Ошибка существовала как минимум начиная с Windows Server 2012 R2 во всех версиях Windows. В начале лета 2025 года мы направили информацию об этом в Microsoft, и результаты недавних тестов показывают, что в актуальных версиях (с майскими обновлениями 2026 года) ошибка была исправлена (ответа о факте исправления мы не получили).

А о нюансах исследования, интересных подробностях представления IP-адресов и подходах к проведению экспериментов, которые помогли найти объяснение, автор рассказал в докладе на прошедшей в мае конференции ËPRSTCON — запись доклада, презентацию и расшифровку ищите на сайте конференции.

И что же теперь делать? 😨

1️⃣ В старых версиях Windows, которые уже не получают обновлений, продолжать обращать внимание на ::%16777216 в логах.

2️⃣ В актуальных версиях Windows, где, возможно, были установлены обновления, дополнительно проверять на наличие ::1 там, где такого адреса не должно быть в норме.

3️⃣ Учитывайте, что есть множество различных утилит для создания туннелей, и подобный индикатор никак не подтверждает использование именно ngrok.

0️⃣ По желанию — доработайте свой парсинг логов так, чтобы восстанавливать нормальный IP-адрес: это поможет учитывать адрес в корреляционных правилах и получать больше релевантных результатов при ретроспективном поиске событий или тредхантинге.

P.S.: и не забывайте обращать внимание на появление 127.0.0.1 в неподходящих местах.

P.P.S.: и не только 127.0.0.1, а любого адреса из сети 127.0.0.0/8: все эти адреса соответствуют интерфейсу localhost согласно RFC5735, и это работает во всех популярных ОС. Использовать как источник адрес типа 127.0.13.37 у злоумышленника вряд ли легко получится, а вот указывать в качестве назначения подобные адреса для подключения к процессам на локальном хосте — вполне.

#tip #win
@ptescalator

Мы сканируем опенсорс в реальном времени в поисках вредоносного кода. А также ответственные в ESCalator за публикации про интересности в Python Package Index и NPM 🏃‍♀️

Рады сообщить о коллаборации с парнями из PT Fusion и выпуске фидов по найденным угрозам в формате OSV (анонс). Там есть информация не только по вредоносным релизам, но и, например, по удаленным пакетам, что тоже является одним из факторов риска, который нужно учитывать при дальнейшем использовании таких пакетов.

Если в вашей компании есть разработка, и вы беспокоитесь о ее безопасности, то будем рады видеть вас в рядах наших пользователей 🤗

#scs
@ptescalator

Спустя неделю после нашумевшего Copy.Fail исследователь v4bel раскрыл новую технику повышения привилегий в ядре Linux — Dirty Frag.

По состоянию на 8 мая у Dirty Frag нет CVE-номера и, что более критично, официального патча от мейнтейнеров ядра тоже нет. Dirty Frag относится к тому же классу, что Dirty Pipe и Copy.Fail, но использует другой механизм: вместо pipe_buffer атакуется структура sk_buff.

Общие механизмы работы позволяют надежно блокировать эксплойт поведенческой экспертизой в PT Sandbox (Exploit.Linux.CVE-2022-0847.a, Exploit.Linux.CVE-2026-31431.a, Backdoor.Linux.Generic.a) — смотрите на скриншоте.

Как это работает? 🧐

Dirty Frag — это цепочка из двух уязвимостей, которые дополняют друг друга, чтобы охватить все основные дистрибутивы:

1️⃣ Page-Cache Write (с 2017 года): предоставляет возможность для записи 4 байт в кэш страниц, но требует права на создание пользовательских пространств имен, что в некоторых системах (например, Ubuntu) может блокироваться AppArmor.

2️⃣ RxRPC Page-Cache Write (с июня 2023 года): не требует прав на пространства имен, но модуль rxrpc.ko присутствует только в некоторых дистрибутивах, включая Ubuntu, где он загружен по умолчанию.

Объединив их, атакующий получает рабочий эксплойт на любой системе, что позволяет:

• Подменить suid-файлы (например, /usr/bin/su) на свою версию
• Изменить /etc/passwd, очистив пароль root-пользователя

Кто под угрозой? ⛳️

Практически все системы с ядром Linux, выпущенные с 2017 года. Исследователь подтвердил работу эксплойта на следующих версиях: Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44 и других.

Как защититься? 🔧

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

Команда для отключения:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Некоторые дистрибутивы (например, AlmaLinux) начали выпускать собственные патчи, не дожидаясь апстрима.

UPD: уязвимость получила идентификатор — CVE-2026-43284, патч добавлен в код ядра (f4c50a4034e6).

#avlab #cve #linux #sandbox
@ptescalator (X, Max)

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf

rmmod algif_aead 2>/dev/null

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

😑 В чем тут проблема: часть констант, из которых собирается итоговое выражение, хранится в памяти. Из-за этого IDA по умолчанию не может нормально применить constant propagation и автоматически «свернуть» такие конструкции в исходные значения (скриншот 1).

Особенно неприятно, когда таким способом маскируют еще и адреса вызываемых функций. На практике это выливается в конструкции вида:

mov   <reg>, <const>
add   <reg>, cs:<offset_*>
call  <reg>

Для статического анализа это, конечно, лишняя головная боль 🧱

Но есть нюанс: если явно указать, что данные по адресу cs:<offset_*> — это константные qword/dword, то во время декомпиляции IDA сама подтянет значение из памяти, пересчитает выражение и свернет его обратно в исходную константу.

Перед тем как явно проставлять таким данным const, стоит убедиться, что значение действительно readonly. Один из простых способов — посмотреть на перекрестные ссылки: если все обращения к адресу идут только на чтение, то это хороший кандидат на const (скриншот 2).

Заодно полезно отфильтровать значения, которые на самом деле являются указателями, чтобы не испортить типизацию (скриншот 3).

😎 Все это можно автоматизировать небольшим IDAPython-скриптом (IDA 9.0+), который проходит по сегменту .data (или любому другому нужному сегменту), находит значения, используемые только на чтение, исключает те, что похожи на адреса, и явно проставляет им const byte/word/dword/qword в зависимости от размера.

В результате псевдокод становится заметно чище и понятнее (скриншот 4).

А вот и этот IDAPython-скрипт:

import ida_bytes
import ida_segment
import ida_typeinf
import idautils
import ida_xref
import idaapi
from collections import namedtuple

PTR_SIZE = 8 if idaapi.inf_is_64bit() else 4


TypeInfo = namedtuple('SizeInfo', ['get_data', 'typename', 'badaddr'])

SIZE_TO_TYPE_INFO_MAP = {
    1: (TypeInfo(ida_bytes.get_byte,  "byte",  0xFF)),
    2: (TypeInfo(ida_bytes.get_word,  "word",  0xFFFF)),
    4: (TypeInfo(ida_bytes.get_dword, "dword", 0xFFFFFFFF)),
    8: (TypeInfo(ida_bytes.get_qword, "qword", 0xFFFFFFFFFFFFFFFF))
}


def apply_const_type(ea: int) -> bool:
    flags = ida_bytes.get_flags(ea)
    if not ida_bytes.is_data(flags):
        return False

    item_size = ida_bytes.get_item_size(ea)
    type_info = SIZE_TO_TYPE_INFO_MAP.get(item_size)
    if type_info is None:
        return False

    if type_info.get_data(ea) == type_info.badaddr:
        return False

    typeinfo_str = "const " + type_info.typename
    tif = ida_typeinf.tinfo_t(typeinfo_str)

    ida_bytes.clr_op_type(ea, 0)
    return ida_typeinf.apply_tinfo(ea, tif, 1)


def is_addr_readonly(target_addr: int) -> bool:
    flags = ida_bytes.get_full_flags(target_addr)
    return ida_bytes.has_xref(flags) and \
           all(ref.type == ida_xref.dr_R for ref in idautils.XrefsTo(target_addr))


def apply_const_type_if_readonly(target_addr: int) -> bool:
    return apply_const_type(target_addr) if is_addr_readonly(target_addr) else False


def data_is_offset(ea:int) -> bool: 
    item_size = ida_bytes.get_item_size(ea)
    if item_size != PTR_SIZE:
        return False
    
    type_info = SIZE_TO_TYPE_INFO_MAP.get(item_size)
    if type_info is None:
        return False
    
    value = type_info.get_data(ea)
    return  (idaapi.getseg(value)) is not None 


def main():
    print("Casting readonly memory values to consts ")
    print("---------------------------------")
    
    segment_name = ".data"
    
    seg = ida_segment.get_segm_by_name(segment_name)
    if not seg:
        print("No {segment_name} segment")
        return

    ea = seg.start_ea
    fixed_consts_num = 0

    while ea < seg.end_ea:
        ea_size = ida_bytes.get_item_size(ea)
        if ea_size <= 0:
            ea += 1
            continue

        if not data_is_offset(ea) and apply_const_type_if_readonly(ea):
            fixed_consts_num += 1

        ea += ea_size

    print("---------------------------------")
    print(f"Done. fixed = {fixed_consts_num} consts")
    print("Decompile again to view results: F5")


if __name__ == "__main__":
    main()

#tips #reverse
@ptescalator (X, Max)

Одной из самых актуальных уязвимостей в Windows Server Update Services (WSUS) стала критическая ошибка с идентификатором CVE-2025-59287 и оценкой CVSS 9.8. Она связана с десериализацией недоверенных данных в службе обновления Windows Server и позволяет неавторизованному удаленному злоумышленнику выполнить код на сервере, отправив специально сформированное событие.

В разборах эксплуатации шаги были указаны некорректно, так как их взяли из статьи. Однако позже авторы сами ее исправили и указали, что разбор относится к CVE-2023-35317, тогда как анализ CVE-2025-59287 перенесли в отдельную статью.

Это вызвало путаницу в многочисленных репостах, поэтому мы решили расставить все точки над i и заодно показать, как атакующий может восстановить оснастку после эксплуатации уязвимости.

❗️ Напомним технические детали эксплуатации

Условия для эксплуатации:

• Сервер Windows с включенной ролью WSUS Server (по умолчанию отключена)
• Неустановленные обновления KB5070879 / KB5070881 / KB5070882 / KB5070883 / KB5070884 / KB5070886 / KB5070887
• Сетевой доступ к портам 8530 (HTTP) или 8531 (HTTPS)
• Учетные данные не требуются

Техническая цепочка эксплуатации:

1️⃣ Получение конфигурации — злоумышленник отправляет запрос к /ReportingWebService/ReportingWebService.asmx для получения ServerID (скриншот 1)

2️⃣ Извлечение cookies — используя ServerID, выполняется запрос к /SimpleAuthWebService/SimpleAuth.asmx для получения AuthorizationCookie (скриншот 2)

3️⃣ Получение криптографических данных — запрос к /ClientWebService/Client.asmx для извлечения временных меток и зашифрованной нагрузки (скриншот 3)

4️⃣ Доставка полезной нагрузки — финальный запрос отправляет событие с вредоносным сериализованным объектом, созданным через ysoserial.net с гаджетом TextFormattingRunProperties, с использованием события SynchronizationCompletedCancel (скриншот 4)

При обработке события с ID 389 (SynchronizationCompletedCancel) WSUS пытается десериализовать XML с телом ошибки, что приводит к выполнению произвольного кода.

Также в процессе эксплуатации регистрируется ложный узел с указанным DNS, в рамках которого отправляется событие. Этот процесс легко автоматизировать — например, с помощью шаблона Nuclei (скриншот 5). Восстановление оснастки после тестирования — на скриншоте 6.

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

Для восстановления необходимо удалить вредоносное событие из таблицы tbEventInstance в базе данных SUSDB. Однако прямой доступ к БД есть только у привилегированных пользователей, а служба WSUS часто запущена от имени Network Service.

При этом служба WSUS имеет доступ к функциям, используемым в оснастке, поэтому пользователь, от имени которого получена сессия (даже Network Service), может управлять зарегистрированными узлами. Это позволяет безопасно завершить эксплуатацию и сразу восстановить оснастку.

$wsus = Get-WsusServer

Get-WsusComputer -NameIncludes "test1337.test.local" | ForEach-Object {
    $wsus.GetComputerTarget($_.Id).Delete()
}

Эта команда выполняет две важные функции:

• Удаляет зарегистрированный ложный узел из базы данных WSUS
• Автоматически очищает связанное с ним событие с ID 389, использованное для доставки полезной нагрузки

🧐 Почему это важно: без очистки в WSUS остаются артефакты — ложный узел и события в логах, что может нарушить нормальную работу службы.

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

Рекомендации по защите

• Установите обновления — KB5070879 / KB5070881 / KB5070882 / KB5070883 / KB5070884 / KB5070886 / KB5070887 в зависимости от версии Windows Server

• Ограничьте сетевой доступ — WSUS не должен быть доступен из интернета. Используйте сегментацию сети для ограничения доступа только доверенным подсетям

• Если невозможно обновить — временно отключите роль WSUS Server или заблокируйте порты 8530 / 8531 до установки патчей

#offensive #nuclei #wsus #cve
@ptescalator (X, Max)