Недавно к нам в песочницу залетел семпл mir-pay.apk. На первый взгляд — ничего необычного: очередная вариация хорошо известного вредоноса Mamont, подумали мы. Тем более что название платежной системы уже не раз встречалось в этом семействе ВПО.

В песочнице сработала метка «Формат подделан» с вердиктом apk.tampered, образец сохранял подозрительные файлы с расширением .png (файловые дропы) и загружал код напрямую в память (DEX-дампы).

Мы решили копнуть глубже — и не зря. В ходе исследования нам удалось:

• Выяснить, что к Mamont этот семпл отношения не имеет — поиск по найденным IoCs вывел нас на вредоносную кампанию Falcon, первые образцы которой были описаны еще в 2022 году.

• Восстановить всю цепочку атаки — от загрузчика фейкового «обновления приложения» до полноценного Android-бэкдора — и разобраться, как злоумышленники используют легитимные сервисы, включая Trello, для доставки вредоносного ПО.

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

О том, как устроена вредоносная кампания Falcon — читайте в подробном анализе в нашем блоге на Хабре.

#avlab #sandbox #ti #android
@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)

https://github.com/sergo20261/proxi/raw/refs/heads/main/претензия.rar

firebasestorage.googleapis.com/v0/b/remasd-6c702.firebasestorage.app/o/image.jpg?alt=media&token=c16438a4-4eeb-4116-adc7-373fbf7359b0
modaaura.store/image.jpg?12711343

https://raw.githubusercontent.com/sergo20261/proxi/refs/heads/main/vc27012026upload.txt

Акт сверки и претензия.eml -> 71a8920aa71afde02a466e08508642561b98a99632351cdd1c1ce3ab805a10ba
pretenziya_27012026_akt_sverka_1C_PDF.bat -> 1d3e6b81479717282fb0f661fba3603b3f9f9c9d857a0f2fa8035b7015ab1f0a
vc27012026upload.txt -> 9abcfce5cb991f60652c4b410e45ad40f4b0eafe30c2209f0c6e6636b424d5db
Rust загрузчик -> 93e0fb947cff4ab361c307590a078549ab9e885d04e23b12a800296dd4d6c4a4
PureHVNC -> 49fde62919aec811780e67073a7e70566594477ef7b19905e1b8aa42438f6d98

62.84.98.217
firebasestorage.googleapis.com/v0/b/remasd-6c702.firebasestorage.app/o/image.jpg?alt=media&token=c16438a4-4eeb-4116-adc7-373fbf7359b0
modaaura.store/image.jpg?12711343

🧪 Мы — команда отдела сетевой экспертизы антивирусной лаборатории ESC и команда машинного обучения — однажды уже построили ML-модель на сетевом трафике, обучили ее на реальных сетевых сессиях и запустили в песочнице PT Sandbox для усиления возможностей по обнаружению вредоносов. Но мы решили не останавливаться на достигнутом — провели серию новых экспериментов, расширили набор входных признаков и протестировали модель на более сложных сценариях.

👾 Благодаря обновлению модель уже успела поймать несколько ранее неизвестных образцов: новую версию бэкдора Oyster, загрузчик APT GOFFEE, несколько стилеров (например, JustAskJacky) и еще ряд небольших, но подозрительных загрузчиков.

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

Обо всем этом и не только рассказали в нашей статье на Хабре.

#network #avlab #ml
@ptescalator

arslan@arsavukatlik.com
bilgi@dermamed.com.tr

gocmenkusgiller.blog

YENI URUNLER ICIN FIYAT TALEBI3.jar
FIYAT TEKLIFI BEKLENEN URUN LISTESI.jar

90ead7a262450a9bace5686f11fc39cbd607a0d681ef9ff39d8766d9b4c0de2e
8dc7f7d298291c042e9f51feff3c8d690f4889a9a141e9657d33da7bb8456c7f

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

Письмо от анонимного отправителя с легитимного домена — info@koyoshobo.net, с явной попыткой привлечения внимания (тема: «Action Required: Document Review…», скриншот 1). Содержимое представляет собой HTML с закосом под форму системы ЭДО с кнопкой для перехода к документу (скриншот 2). Из страницы статически извлечена ссылка на «документ» по данной кнопке:

https://click.convertkit-mail2.com/75u5pv4wxga8h69dp74fzhwl85666tnhrg6p3/m2h7h5h38zwp97cm/aHR0cHM6Ly93d3cubXRmcGxhc3RpY29zLmNvbS5ici9vb3BzL3NoYXJlZmlsZWRvYy5tc2k

На момент атаки ссылка была новой и не заблокировалась репутационным анализом. Она была автоматически запущена в изолированной браузерной среде, в результате чего удалось получить все перенаправления (скриншот 3) и прийти к итоговой ссылке на «документ» — https://www.mtfplasticos.com.br/oops/sharefiledoc.msi, выкачав для проверки файл 04276b7f1cf487e52f8927134365ae55, очевидно являющийся исполняемым.

💁‍♂️ На этом можно было бы закончить — исполняемые файлы на почте можно легко заблокировать (главное, обратите внимание, чтобы в вашем средстве защиты блокировка осуществлялась по формату файла, а не исключительно по расширению), например, как показано на скриншоте 4 в случае с PT Sandbox. Но если вам нужна гибкая конфигурация, позволяющая обмениваться различными файлами и ссылками на них через почту, всегда важно понимать, что именно представляет собой файл. Для этого в базовых средствах защиты предусмотрена антивирусная проверка, а в продвинутых — проверка файла в песочнице, позволяющая обнаружить самые изощренные угрозы и новое ВПО, еще не засветившееся в антивирусных базах.

Песочница сразу дала понять поведение и сетевую суть семпла (скриншот 5) и заблокировала его за опасные трюки в PowerShell — внутри оказалась утилита PDQ Connect. «И что же тут вредоносного?!» — спросите вы. А мы ответим — несанкционированные политикой ИБ утилиты удаленного доступа сами по себе являются запрещенными 🙅‍♂️

Но тут все чуть сложнее — исходный MSI-файл не просто обобщенный установщик ПО PDQ Connect, это «тихий» установщик PDQ Connect Agent, который генерируется индивидуально для пользователя, с уникальным токеном, и разворачивается в рамках инфраструктуры организации. Если злоумышленник сгенерирует такой установщик и установит его кому-то без его ведома, то данная утилита превращается в самый настоящий бэкдор. Анализ в песочнице позволил автоматически получить токен агента — 0yfer-ks1g2uufaxwpfam81pmasj9bk5e-q7btltzsrkhvz4xxyoonu8cb7kokkd7fc6esztcx1uqccmabxn3w.

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

🔍 Характерные строки YARA, которые помогут вам найти артефакты от подобных «агентов» в ваших системах:

strings:
        $a  = "pdqconnectagent-setup" ascii wide
        $s1 = "PDQ.com" fullword wide
        $s2 = "CustomActions.StartService" wide
        $s3 = "CustomActions.WriteToken" wide
        $s4 = "CustomActions.DeleteEvent" wide
        $s5 = "CustomActions.CreateEventSource" wide
        $s6 = "CustomActions.CleanData" wide
    condition:
        (uint16(0) == 0x5a4d or (uint32be(0) == 0xd0cf11e0 and uint32be(4) == 0xa1b11ae1))
        and $a
        and 3 of ($s*)

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

#phishing #malware #emailsecurity #sandbox #avlab
@ptescalator

В процессе мониторинга новых сетевых угроз в отделе сетевой экспертизы был замечен подозрительный трафик, который порождался файлом INTIMACAO_2025_006647.exe. Он маскировался под PDF и в переводе с португальского означал «Вызов в суд» (скриншот 1).

После запуска на хосте открывался документ-приманка и инициировалось сетевое взаимодействие с API Google, причем внешне оно было похоже на легитимные запросы, а не на типичный обмен с C2. Эта история нас заинтриговала, поэтому мы решили углубиться в анализ образца и понять, что именно он делает и какую роль в этой схеме играют неожиданные сетевые запросы к Google 🔍

Сразу перейдем к поведенческому анализу. После запуска в директорию /Temp дропались несколько PowerShell-скриптов: Clean_policies, Get_token и Apply_cbcm. Суть работы первого заключалась в подготовке зараженной машины — зачистке реестра от уже существующих локальных политик и настроек различных Chromium-браузеров, а также перезапуске браузерных процессов для оперативного применения внесенных изменений (скриншот 2). После этого Get_token.ps1 обращался к удаленному серверу и вытягивал оттуда некий токен (скриншот 3). В завершение третий скрипт, Apply_cbcm (скриншот 4), записывал полученный токен в политики Chrome на уровне системного реестра.

🙆 После более внимательного взгляда на имена параметров все стало достаточно прозрачно: вредонос проставлял CloudManagementEnrollmentToken и включал CloudPolicyOverridesPlatformPolicy, то есть явно переключал браузер на приоритет облачных политик. Такой набор названий практически прямым текстом указывал на использование Chrome Browser Cloud Management (судя по блогу Google Cloud, этот механизм должен был бороться со злом, а не примкнуть к нему) и на то, что основная цель здесь — привязать браузер к удаленной консоли управления, созданной злоумышленником.

Именно последствия работы этих скриптов мы в первую очередь и увидели в сетевом дампе (скриншот 5). Сначала обычным GET-запросом на C2 servidorunico.com возвращался тот самый enrollment-токен. Далее, после того как значение оказывалось прописано в реестре, браузер автоматически поднимал следующий этап цепочки — сам инициировал регистрацию в инфраструктуре Google и отправлял POST на API-эндпоинт с параметром request=register_browser. Ключевой маркер в этом запросе находился в заголовке Authorization, где токен передавался как GoogleEnrollmentToken, и именно это превращало внешне легитимный трафик к Google в индикатор привязки браузера к удаленному облачному управлению.

🌐 Такая тактика дает злоумышленнику устойчивый рычаг управления браузером. Как только пользователь «попался», атакующий получает возможность централизованно развернуть вредоносные политики и расширения либо настроить прокси для перехвата трафика. Самое неприятное — часть активности выглядит как легитимное администрирование, поэтому без контекста такую компрометацию довольно легко пропустить.

Stay tuned and happy hunting!

IoCs:

SHA256: 4442e1b545f0a571af113b0cc7455ecba1a603c81bbf84a52b9e61d332f97233
C2: servidorunico.com

#network #C2 #phishing #AVLab
@ptescalator

В PT ESC открылась Антивирусная лаборатория: мы объединили экспертизу «ВИРУСБЛОКАДА» с нашей, анализируем множество сэмплов и самостоятельно пишем сигнатуры для антивирусной базы.

🌚 Более того, на днях эксперт Позитива впервые создал детектирующую запись для антивирусного движка. А перед этим освоил теорию и практику новой для нас технологии и навык использования необходимого набора инструментов. Сможете угадать название детекта? Голосуйте в опросе ниже.

Если у вас есть интересный вредонос, который надо проанализировать и для которого необходимо создать правила обнаружения в наших продуктах, то не стесняйтесь: avlab@ptsecurity.com

#avlab
@ptescalator

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

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

🔓 Как защищен?

.NET Reactor использует несколько уровней защиты для предотвращения декомпиляции и анализа кода:

• NecroBit IL Code Protection: заменяет CIL-код методов на зашифрованный, делая невозможной декомпиляцию и восстановление исходного кода.

• Виртуализация кода: преобразует исходный код в набор инструкций отличный от .NET IL, которые интерпретируются во время выполнения виртуальной машиной, что затрудняет анализ и восстановление оригинального кода.

• Обфускация потока управления (Control Flow Obfuscation): преобразует код методов в запутанную структуру, усложняя понимание логики программы и затрудняя работу декомпиляторов (пример — на скриншоте 1).

• Шифрование строк (String Encryption): шифрует строки в коде, предотвращая их чтение и анализ, что усложняет понимание функциональности приложения, как показано на скриншоте 2.

• Антиотладочные механизмы (Anti Debug): внедряет проверки на наличие отладчиков, завершая процесс при их обнаружении, что препятствует динамическому анализу приложения.

🆕 Что нового?

• Поддержка .NET 6.0: обеспечивает защиту для новейших приложений на этой платформе.

• Улучшения в виртуализации кода и Control Flow Obfuscation обеспечивают дальнейшее повышение надежности и сложности обфускации.

• Скрытие содержимого объединенных приложений .NET Core, 5.0, 6.0 предотвращает просмотр содержимого с помощью инструментов, таких как ILSpy / dnSpy.

🧐 Как анализировать?

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

• дешифровка NecroBit — восстанавливает CIL-код из зашифрованных методов;

• удаление прокси и оберток — очищает код от мусора, добавленного обфускатором (смотрите на скриншоте 3);

• декодирование строк и ресурсов — возвращает читаемые строки, зашифрованные в приложении;

• обход антиотладки и защиты от изменения кода.

Однако начиная с версии 6.9 изначальная версия Net Reactor Slayer перестала справляться с деобфускацией защиты даже с базовыми параметрами. Благодаря открытому исходному коду и довольно большому комьюнити, в pull requests можно найти исправленный код, который прекрасно отрабатывает даже на самой свежей версии обфускатора.

Но вот с виртуализированным кодом не все так гладко: Net Reactor Slayer с ним не справляется. Если вам повезло и файл был защищен версией 6.9.0.0, то можно не тратить время на ручной анализ виртуальной машины, а применить VMAttack — инструмент для девиртуализации приложений .NET, в котором есть поддержка этой версии .NET Reactor. А если не повезло — проще всего проанализировать файл по его поведению, например с помощью PT Sandbox.

☝️ Вывод

.NET Reactor остается одним из самых популярных обфускаторов для .NET. С каждой версией защита усложняется, особенно за счет виртуализации. Если собираетесь его анализировать — запасайтесь терпением и хорошими инструментами.

#avlab #sandboxteam #dotnet #obfuscation
@ptescalator

0: kd> dx @$explorer = "explorer.exe"
0: kd> bp /w "@$curprocess.Name.ToLower().StartsWith(@$explorer)" nt!NtCreateFile "dx ((_OBJECT_ATTRIBUTES*)@r8)->ObjectName->Buffer; gc"

"use strict";

function WriteMemoryCallback()
{
    if  (host.currentThread.Registers.User.rcx == -1)
    {
        return;
    }

    let address = host.currentThread.Registers.User.rdx; 
    let buffer  = host.currentThread.Registers.User.r8;
    let length  = host.currentThread.Registers.User.r9;
    let filename = ${host.currentProcess.Name}-${buffer.toString(16)}.dmp;

    let file = host.namespace.Debugger.Utility.FileSystem.TempDirectory.CreateFile(
        filename, 'CreateNew');

    file.WriteBytes(host.memory.readMemoryValues(buffer, length, 1));
    host.diagnostics.debugLog(`dumped ${length} bytes to ${filename}\n`);
    file.Close();
}

function initializeScript()
{
    return [new host.apiVersionSupport(1, 9)];
}

function invokeScript()
{
    let bp = host.namespace.Debugger.Utility.Control.SetBreakpointAtOffset("NtWriteVirtualMemory", 0, "nt");
    bp.Command = `dx @$scriptContents.WriteMemoryCallback(); gc`;
}

let exec = host.namespace.Debugger.Utility.Control.ExecuteCommand;
let command = `dx @$scriptContents.BreakPointCallback(); gc`;
exec("bc *");
exec(`bp 0xfffffc024d546a88 "${command}"`);

const log  = x => host.diagnostics.debugLog(x + '\n');
const u64  = x => host.memory.readMemoryValues(x, 1, 8)[0];
const exec = x => host.namespace.Debugger.Utility.Control.ExecuteCommand(x);

function ParseCallbacks(Symbol, Size)
{
    log([+] ${Symbol}:);
    let base = host.getModuleSymbolAddress("nt", Symbol);
    if (base == null)
        return;
    for (let i = 0; i < Size; i++)
    {
        let entry = u64(base.add(i * 8));
        if (entry.compareTo(0) != 0)
        {
            entry = entry.bitwiseAnd(-16);
            let callback = u64(entry.add(8));
            log(\t${exec(.printf "%y", ${callback}).First()});
        }
    }
}

function CallbackEnumerator()
{
    ParseCallbacks("PspCreateProcessNotifyRoutine", 64);
    ParseCallbacks("PspCreateThreadNotifyRoutine", 64);
    ParseCallbacks("PspLoadImageNotifyRoutine", 8);
}

function initializeScript()
{
    return [new host.apiVersionSupport(1, 7),
            new host.functionAlias(CallbackEnumerator, "callbacks")];
}