А помните, мы рассказывали, как злоумышленники могут без авторизации производить перебор доменных пользователей через интерфейс MS-NRPC? На самом деле, это часть большого исследования нашего эксперта Хайдара Кабибо. Исследование посвящено одной из самых сложных технологий в ОС Windows: многоуровневой системе коммуникации Inter-Process Communication (IPC). Частью этой системы является и протокол RPC (Remote Procedure Call), который используется в упомянутой выше атаке.

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

Первая часть представляет общий план исследования: оно покрывает все четыре уровня организации IPC, от самого высокого (DCOM) до технологий уровня ядра (Named Pipes, ALPC).

Во второй части автор разбирает интерфейс RPC и показывает, как создавать собственные RPC-серверы и клиенты.

Третья часть посвящена дескрипторами привязки (Binding Handles), которые используются в RPC для управления соединениями между сервером и клиентом.

А в четвёртой части вы узнаете, как организована безопасность RPC. Здесь и объясняется, почему некоторые действия в этом протоколе можно выполнять с более низким уровнем аутентификации, чем вы ожидали; в частности, интерфейсы многих RPC-северов разрешают доступ безо всякой авторизации вообще.

И это ещё не всё! Продолжение исследования – читайте в блоге Хайдара по мере публикации.

Мейнфреймы, то есть высокопроизводительные серверы IBM на базе операционки z/OS, появились более 60 лет назад. С тех пор различные аналитики много раз "хоронили" этих динозавров, предсказывая их вытеснение с рынка более современными решениями типа Google Cloud, AWS или Azure.

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

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

В новой статье-продолжении наши эксперты Денис Степанов и Александр Коротин рассказывают о внутреннем устройстве пакета безопасности RACF, который является наиболее популярным решением для обеспечения безопасности в z/OS.

RACF содержит информацию о различных объектах, используемых внутри z/OS — пользователях, группах, датасетах и многих других, и устанавливает множество взаимосвязей и зависимостей между ними. Это очень похоже на Active Directory, с тем лишь отличием, что вместо OU и GPO вы встретите профили, ресурсы и скрытые связи, влияющие на контроль доступа и позволяющие выполнить "неочевидные" атаки по повышению привилегий на мейнфрейме.

Кроме этого, вас ждёт:

— описание нашей утилиты racfudit, которая позволяет извлекать ценную информацию из базы данных RACF.

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

— алгоритмы, используемые в z/OS для хранения учётных данных пользователей (паролей и парольных фраз).

Всё это — в статье "Подход к тестированию на проникновение мейнфреймов на базе z/OS. Погружение в RACF".

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

Однако детальная информация, касающаяся условий логирования и интерпретации данных UserAssist, до сих пор остаётся непубличной. Поэтому специалисты из нашей команды реагирования на инциденты провели тщательное исследование UserAssist — и разъяснили, с чем связано неоднозначное представление данных в этом артефакте. А изучение структуры UEME_CTLSESSION, отвечающей за текущую сессию логирования, позволило раскрыть назначение ранее не задокументированных бинарных данных UserAssist.

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

Новая утилита также добывает данные из структуры r0, где хранятся сведения о частоте использования программ конкретным пользователем — это помогает выявить запуск подозрительных (новых или редко используемых) программ.

Все подробности исследования — в статье "Артефакт UserAssist: потенциал для реагирования на инциденты"

Как злоумышленник может обойти MDR-сервис? Самый простой вариант: найти в атакуемой организации хосты, которые не покрыты мониторингом.

Такую целевую атаку на государственные IT-службы в Африке недавно выявили аналитики из нашей команды MDR. Источником подозрительной активности (запуск модулей WmiExec и Atexec из набора инструментов Impacket) оказался скомпрометированный хост, не подключенный к мониторингу. Этими командами атакующие проверяли доступность своего С2-сервера.

После завершения работы модулей Atexec и WmiExec атакующие временно затаились, а затем стали анализировать запущенные процессы и занятые порты, чтобы понять, установлены ли на целевых хостах какие-либо решения безопасности (EDR-, MDR- или XDR-агенты). Собранные данные о незащищенных хостах использовались для развития атаки.

Впоследствии, когда скомпрометированный хост (веб-сервер IIS) был подключен к мониторингу, на нем были найдены различные артефакты атаки, включая имплант Cobalt Strike.

Мораль: агенты решений безопасности должны быть установлены на всех рабочих станциях организации. Чем полнее данные телеметрии, тем полноценнее будет реагирование.

Подробности расследования и IoCs - в статье по ссылке.

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

Но помимо небольших "домашних" сетапов с парой-тройкой умных лампочек и счётчиков воды, протокол Zigbee активно используется в крупных промышленных системах автоматизации, включающих целые производственные конвейеры и роботов. Успешный взлом такой Zigbee-сети даёт злоумышленнику много интересных возможностей — от проведения разрушительной DOS-атаки на промышленное оборудование до перехвата управления сетевым координатором, через который можно получить доступ ко множеству разнообразных сенсоров и датчиков.

На одном недавнем митапе наш эксперт Хайдар Кабибо рассказал, как анализировать безопасность Zigbee-сетей, где не помогают классические автоматизированные инструменты пентестера. В ходе доклада было показано:

— как с помощью недорогого USB-донгла можно сниффать сетевой трафик, как его расшифровать, где найти ключи шифрования и что делать, получив их;

— как создавать Zigbee-пакеты для перехвата коммуникации между сетевым координатором и его датчиками, полностью имитируя функции координатора;

— какими простыми трюками можно сбить с толку узлы Zigbee-сети и заставить их вести себя непредсказуемо.

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

Утилита sudo даёт пользователям Linux и UNIX-подобных систем возможность выполнять команды от имени суперпользователя root, если это нужно для решения определённых задач. В норме такое повышение привилегий контролируется админами через правила конфигурации sudo и не создаёт проблем.

Однако этим летом в sudo были найдены уязвимости CVE-2025-32462 и CVE-2025-32463, которые позволяют атакующему производить локальное повышение привилегий.

В новых версиях sudo обе уязвимости исправлены. Но sudo инсталлируется по умолчанию на большинстве популярных дистрибутивов Linux – и не исключено, что вы ещё используете неисправленную версию. Поэтому рекомендуем изучить наши инструкции по детектированию и защите.

Что такое CVE-2025-32462?

Данной уязвимости подвержены версии sudo с 1.8.8 до 1.9.17. Опция -h / --host используется при запуске sudo в сочетании с ключом -l (просмотр привилегий) для проверки привилегий на удаленном хосте. Однако в уязвимых версиях эту опцию можно использовать с любой командой.

Поэтому, если в конфигурациях sudoers параметр "host" выставлен в значение, отличное от ALL или имени текущего хоста, атакующий может при вызове sudo указать любой хост и обойти ограничение правил sudoers, связанных с именем хоста.

Как защититься:
– Установить версию, в которой исправлена данная уязвимость – sudo 1.9.17p1;
– Проверить правила в /etc/sudoers*, использующие привязку к узлу, и по возможности переписать их на другие виды, не использующие host-параметр, например, на групповые правила (%group).

Как детектировать эксплуатацию:
Отслеживайте попытки выполнить sudo с ключом -h / --host без применения ключа -l в командной строке запуска процессов sudo. Например, так будет выглядеть попытка эксплуатации, ведущая к запуску whoami:

sudo -h random-hostname whoami

Что такое CVE-2025-32463?

Эта уязвимость затрагивает версии sudo с 1.9.14 по 1.9.17. Уязвимость связана с опцией -R / --chroot. При выполнении команды в chroot-окружении файл конфигурации /etc/nsswitch.conf загружается не в контексте системного каталога, а в контексте корневого каталога, которым может послужить любой пользовательский каталог с размещенным там файлом /etc/nsswitch.conf.

Файл /etc/nsswitch.conf (Name Service Switch configuration) в Linux и UNIX-подобных системах определяет порядок и источники, из которых система будет получать информацию о пользователях, группах, хостах, именах доменов, паролях, сетевых сервисах и других ресурсах.

Атакующий может создать вредоносную библиотеку libnss_*.so в любом каталоге, к которому текущий пользователь имеет доступ (например /tmp), и там же разместить поддельный файл /etc/nsswitch.conf с настройками для запуска этой библиотеки. Если после этого запустить команду sudo с ключом -R / --chroot и указанием расположения каталога с подменённой конфигурацией и вредоносной библиотекой, произойдёт выполнение вредоноса с правами root.

Как защититься:
– Установить версию, в которой исправлена данная уязвимость – sudo 1.9.17p1;
– По возможности ограничить доступ для непривилегированных пользователей к общедоступным каталогам в части опций mount, nosuid, nodev, noexec;
– Опционально добавить параметр Defaults !use_chroot в файл /etc/sudoers, отвечающий за отключение возможности использования chroot для sudo, и пересмотреть правила runchroot=*, отвечающие за разрешение использования chroot.

Как детектировать попытки атак:
– Обращайте внимание на запуск sudo с ключами --chroot / -R;
– Отслеживайте активности, связанные с компиляцией библиотек с паттерном libnss_*.so в имени. Например, атакующий может использовать набор компиляторов gcc для компиляции вредоносной библиотеки непосредственно на атакованном узле. Пример такой команды:

gcc -shared -fPIC -Wl,-init,test -o libnss_/test.so.2 test.c;

– Мониторьте попытки создания конфигурационного файла nsswitch.conf и библиотек libnss_*.so в директориях, отличных от расположения легитимных файлов системы;
– Отслеживайте активности, связанные с переименованием файлов, где целевое имя файла содержит паттерн libnss_*.so.

Часто на проектах без латиницы (русский, 漢語, اللُّغَةُ العَرَبِيَّة, 👄🗣💬🔤) встречается ситуация, когда API отдаёт json-ы с экранированным текстом (Unicode Escaped). В таком тексте символы Unicode закодированы в виде последовательностей типа \u043f\u0440\u0438\u0432\u0435\u0442. Так обеспечивается поддержка национальных языков в системах, которые работают только на дефолтном языке.

Чтобы понять содержимое подобного текста, обычно приходится либо настраивать Hackvertor, либо декодировать контент через Python, что не очень удобно. Также на просторах Интернета можно найти плагины для Burp, которые преобразовывают Unicode Escaped-последовательности – однако написаны они были давно и уже не работают в последних версиях Burp.

Поэтому наш эксперт Евгений Великоиваненко написал свой плагин UnUnicode, позволяющий лёгким движением руки преобразовывать json-ы с экранированными символами в удобочитаемый формат. Плагин может работать во вкладках Proxy и Repeater, а также работает с вебсокетами.

Скачать UnUnicode можно в нашем Гитхабе либо в BappStore.

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

Почему Discovery сложно отследить? Потому что таких событий может быть очень много в типовой организации: выполнение whoami или net user может оказаться легитимной активностью администратора. Реагировать на каждую такую команду не получится, особенно в случае MSSP-провайдера (таких срабатываний за сутки могут быть миллионы).

Но иногда можно обнаруживать подозрительную активность и по таким командам. Один вариант – заметить их повторение (серию): атакующие обычно выполняют сразу несколько команд энумерации.

Другой вариант: выявлять нетипичную связь parent-child процессов. К примеру, довольно точным оказывается мониторинг выполнения discovery-команд, у которых родитель – процесс MSSQL-сервер.

На приложенном скриншоте – именно такой пример, который мы наблюдали у одного из клиентов.

На прошлой неделе состоялось награждение победителей премии Pentest Awards. Поздравляем нашу коллегу Ирину Беляеву, которая получила третье место в номинации "Пробив инфраструктуры"! А теперь краткий пересказ проекта Ирины – как через принтер в переговорке удалось добраться до промышленной системы управления:

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

– Проэксплуатировав известные уязвимости, в том числе уязвимость удаленного исполнения кода, в веб-интерфейсе Scan2Net, мы получили учетную запись доменного пользователя – и с помощью этой учетной записи провели атаку PetitPotam. А так как контроллер поддерживал аутентификацию по протоколу NetNTLMv1, удалось провести ещё и успешную атаку NTLM Relay на контроллеры домена и получить привилегии администратора домена.

– Затем, используя контроллер домена как прокси-сервер, мы снова провели разведку и нашли уязвимый TeamCity. С помощью публичного эксплойта получили админский доступ в веб-интерфейс и создали резервную копию единственного проекта, в настройках которого было задано множество переменных окружения. Для шифрования секретов использовался ключ по умолчанию, и мы смогли получить из резервной копии учетные данные и API-ключи для нескольких сервисов, приватный ssh-ключ и пароль для него. Среди секретов были и учетные данные для Cisco ISE API.

– Потратив некоторое время на чтение документации и обращения к API, мы обратили внимание на группу эндпоинтов, название которой навело на мысль, что для эндпоинтов в этой группе используется тип аутентификации MAC Authentication Bypass, и в что этой группе есть устройства администраторов. Задали своему сетевому интерфейсу один из MAC-адресов из этой группы и получили неограниченный доступ в сеть, в том числе к сетевой доступ сегментам АСУ ТП.

Красным командам эта история будет полезна как подсказка для аналогичного пробива, а синим командам стоит подглядеть, на что обратить внимание для детекта таких атак.

Техника атаки BYOVD (Bring Your Own Vulnerable Driver) очень раздражает создателей защитных решений: злоумышленник просто находит очередной уязвимый драйвер с высокими привилегиями на уровне ядра ОС, и использует этот драйвер для прерывания процессов, запущенных продуктами безопасности.

В одном из прошлых постов про BYOVD мы рекомендовали для борьбы с подобной атакой отслеживать создание символических ссылок. Аналогичным образом можно написать и другие правила для выявления манипуляций с памятью (детектировать вызовы определённых функций, которые производят чтение и запись). Либо можно импортировать себе в SIEM длинный список уязвимых драйверов и отслеживать их запуск.

Но давайте посмотрим на проблему с другой стороны: а как атакующий "приносит" уязвимый драйвер?

Вот свежий пример: при расследовании инцидента в Бразилии наши специалисты нашли вредоносную программу, которая вырубает антивирусы самых известных производителей (см. скриншот). Для этого вредонос опирается на легитимный драйвер ThrootleBlood.sys (ThrottleStop.sys), используемый приложением для повышения производительности CPU. У драйвера обнаружилась очень удобная уязвимость: функции чтения и записи в физическую память из пользовательского режима безо всякой проверки прав.

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

Значит, можно было избежать инцидента, применив вполне стандартные меры защиты:

— ограничение публичного доступа к RDP (при необходимости доступа использовать MFA),
— жёсткая парольная политика, исключающая brute force,
— контроль доступа приложений (белый список),
— сегментация и изоляция корпоративных сетей, чтобы не допустить горизонтальное перемещение в случае взлома.

А подробности расследования бразильского инцидента читайте в статье "Как злоумышленники отключают антивирусы с помощью легитимного драйвера".

Продолжаем публиковать кейсы наших экспертов-участников конкурса Pentest Awards. Поздравляем Виктора Зварыкина, который с рассказом "4911" стал фаворитом года по версии жюри (да-да, есть и такая награда, вне номинаций)!

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

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

– Работы по пентесту проходили в большой финансовой компании. Одна из задач – проверка получения доступа в личный кабинет клиента финансовой организации и доступа к чувствительной информации.

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

В приложении использовался второй фактор для аутентификации, и его требовалось обойти. Отправили на удачу цифровое значение "4911". Да, это звучит как фантастика, но обход получился с первой попытки: значение было принято приложением как валидное. Таким образом и был получен доступ в личный кабинет клиента.

Как избежать подобных атак:

– Мониторьте утечки данных из публичных источников и регулярно меняйте пароли пользователей.

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

– А ещё лучше внедрить MFA вместо 2FA, ведь злоумышленники уже давно научились обходить двухфакторку самыми разными способами.

Среди различных способов дампа учётных данных LSASS (T1003.001) у злоумышленников всё ещё популярен вариант с использованием механизма Silent Process Exit.

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

Последовательность атаки:

– сконфигурировать в реестре параметр Silent Process Exit для процесса LSASS на создание полного дампа при завершении процесса,
– послать операционной системе триггер на принудительное завершение процесса: это можно сделать с помощью штатного сервиса Windows Error Reporting (Werfault.exe),
– после краша процесса LSASS на диске будет создан дамп памяти процесса.

Как детектировать атаку:

Следует контролировать изменение ключей реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\lsass.exe\*
(на приложенном скриншоте – как раз такой пример).

На конкурсе Pentest Awards наш эксперт Виктор Зварыкин стал не только фаворитом по версии жюри: другой кейс Виктора вошёл в топ-10 в номинации "Пробив инфраструктуры". Поэтому предлагаем вам ещё одну историю на чашечку кофе – о том, как полезно читать документацию. Вот как это было:

– Работы проводились удаленно с недоменного хоста с Windows OS, доступ к которому шел через редиректор и reverse ssh. В результате сканирования мы обнаружили хосты с веб-интерфейсом Algosec. После изучения документации были успешно подобраны учетные данные для входа по протоколу ssh.

Затем с помощью tcpdump на хосте в трафике обнаружили зашифрованные учетные данные для входа в веб-интерфейс Algosec. Изучив еще одну документацию и использовав built-in инструмент "fa_password", мы эти учетные данные успешно расшифровали.

После чего переиспользовали учётки на других сервисах – и получили административный доступ в веб-интерфейс Palo Alto. В PAN-OS могут использоваться учётные записи от сторонних сервисов, например LDAP или SMTP. По умолчанию в Palo Alto используется дефолтный мастер-ключ. Он не был изменен, и нам удалось успешно расшифровать пароль доменной учетной записи.

Для повышения привилегий в домене использовался вектор атаки типа relay, с принудительной аутентификацией контроллера домена к службе Web Enrollment центра сертификации (ESC8). Для этого был выполнен вход по протоколу ssh с port forwarding 445 порта на хост Algosec, запущена утилита socat для ретрансляции входящего трафика на 445 порту, и на удаленном хосте Исполнителя через proxychains запущена утилита ntlmrelayx.

Использовав инструмент типа "coerce" dfscoerce.py, мы успешно осуществили принудительную аутентификацию контроллера домена на хост Algosec и ретранслировали к службе Web Enrollment. Далее был получен TGT-билет машинной учетной записи контроллера домена, в результате чего мы получили доступ к файлу базы данных NTDS.DIT и административные права в домене.

Мораль: Если вы не меняете дефолтные ключи и конфиги – возможно, к вам пробьются аналогичным путем.

Защита: Как обнаружить, что кто-то крафтит ваш TGT, мы уже писали. Что ещё подкрутить, чтобы было безопасно? Читайте рекомендации в полной версии кейса (в авторской редакции) на нашем гитхабе.

Если в результате расследования инцидента вы нашли признаки определённого злоумышленника – это ещё не значит, что он был единственным, кто вас атаковал. При этом методы «взаимодействия» атакующих могут быть очень разнообразными.

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

А вот другой пример. Зашифровали инфраструктуру жертвы, для виндового сегмента использовали Conti, для серверов ESXi – шифровальщик Babuk. Расследование цепочки атаки привело нас к одному серверу, который оказался довольно интересным с точки зрения ретроспективного анализа: один из злоумышленников нашёл там уязвимость, проэксплуатировал её, а затем установил обновление безопасности, чтобы не дать другим атакующим воспользоваться той же уязвимостью.

Иными словами, плохие парни могут не только пользоваться наработками конкурентов, но и наоборот – препятствовать проникновению конкурентов на свою поляну.

Подробности обоих упомянутых кейсов, а также другие примеры на эту тему – слушайте в докладе нашего эксперта Алины Сухановой «Когда цель одна, а атакующих много: конкуренция за жертву» (OFFZONE, 22 августа, 12:00)

Если вы ещё не решили, какие доклады слушать во второй день конференции OFFZONE (то есть сегодня) – предлагаем пару подсказок от наших специалистов по цифровой разведке.

Вот например, на схеме выше – хронология событий вокруг некогда популярной киберпреступной платформы RaidForums и пришедшей ей на смену площадке BreachForums. За три последних года эти хакерские форумы пережили несколько закрытий, параллельно с захватами серверов полицией, арестами владельцев и сменой админов.

Как строятся отношения в тёмной части Интернета, если репутация разрушается прямо на глазах? Александр Забровский предлагает свои наблюдения и прогнозы в докладе «Кризис доверия в Даркнете: DFI» (22 августа, 11:00)

И ещё одно исследование трендов Даркнета – о том, как злоумышленники используют игровые платформы. Кража цифровых личностей игроков с помощью малварных логов, таргетированные атаки через Youtube, фальшивые красотки-геймерши и другие креативные мошеннические схемы – в докладе Полины Третьяк «Вы не можете спать, пока рядом есть монстры» (22 августа, 13:20)

Чтобы избежать раздачи рутового доступа кому попало, в операционке Linux привилегии суперпользователя разделяются на отдельные единицы, которые называют «возможностями» (capabilities). Такие root-права дают исполняемым файлам ограниченные разрешения, даже если файл исполняется как root.

Обычно capabilities ограничены по умолчанию: если их устанавливает непривилегированный пользователь, такие права связываются с пользовательским пространством имён (namespace) – и не могут применяться за пределами этого namespace.

Однако эксплоит Game Over(lay) использует две уязвимости в системе OverlayFS (CVE-2023-2640 и CVE-2023-32629), чтобы обойти это ограничение. Эксплоит заставляет систему скопировать файл с ограниченными правами в другое место – где права не ограничены. После этого пользователь без привилегий может выполнить такой файл с рутовыми правами.

Как устроена атака:

OverlayFS – это объединенная файловая система, которая даёт пользователю общее представление разных каталогов в виде «слоев». Это позволяет обмениваться данными и модифицировать их, не изменяя оригинальный контент.

Система устроена так:
– нижний слой (lowedir): монтируется только для чтения,
– верхний слой (upperdir): позволяет записывать модификации,
– рабочий слой (workdir): для управления рабочим каталогом контейнеризованных процессов,
– объединенный слой (merged): доступен пользователю как объединенное представление файловой системы.

Оригинальные файлы хранятся в нижнем слое, только на чтение. При модификации файла или его метаданных активируется механизм Copy-on-Write (CoW), который копирует файл на верхний слой, оставляя оригинал на нижнем.

В некоторых версиях Ubuntu система OverlayFS не проводит валидацию при копировании файлов между слоями. Это позволяет заменить ограниченные root-права на неограниченные одной строчкой команд:

unshare -rm sh -c "mkdir l u w m && cp /u*/b*/p*3 l/; setcap cap_setuid+eip l/python3;mount -t overlay overlay -o rw,lowerdir=l,upperdir=u,workdir=w m && touch m/*; u/python3 -c 'import os;os.setuid(0);os.system(\"bash\")'";rm -rf l u w m

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

unshare -rm создаёт и монтирует новое пространство имён (namespace) пользователя, которому будут предоставлены рутовые права,

mkdir создаёт четыре каталога (l, u, w, m) для «ловушки» OverlayFS.

cp копирует бинарный файл python3 в каталог l, нижний уровень (только чтение). Путь /u*/b*/p*3 обфусцирует реальный путь /usr/bin/python3.

setcap cap_setuid+eip назначает файлу ограниченные рутовые права (capabilities), позволяя ему вызов setuid(0). Эта возможность работает только внутри пользовательского namespace.

mount создаёт OverlayFS с каталогами l (нижний слой), u (верхний слой), w (рабочий слой) и m (объединенный слой). В нижнем слое лежит python3 (с ограниченными правами).

touch модифицирует метаданные файла через каталог m, активируя Copy-on-Write. В уязвимых версиях Ubuntu это приводит к копированию файла python3 в каталог u, где у бинарника будут неограниченные права (за пределами namespace).

Теперь файл python3 можно запустить для повышения привилегий через os.setuid(0) и создать рутовый shell, используя os.system("bash").

Последняя команда rm зачищает каталоги «ловушки».

Как избежать атаки:

Уязвимостям подвержены версии ядра от v5.4 до v6.3. Информацию по обновлениям смотрите здесь: CVE-2023-2640 и CVE-2023-32629.

Также рекомендуется ограничить возможность создания namespace для непривилегированных пользователей:

echo kernel.unprivileged_userns_clone=0 | sudo tee /etc/sysctl.d/99-disable-unpriv-userns.conf

Как детектировать атаку:

– Отслеживайте нестандартное использование unshare, особенно с флагами namespace.
– Выявляйте shell-процессы с подозрительными аргументами, которые предполагают установку рутовых прав (capabilities) и монтирования с перекрывающимися слоями.
– Мониторьте подозрительные родительские shell-процессы, которые могут означать повышение привилегий.

Этим летом злоумышленники атаковали по всему миру сервера SharePoint, получая полный контроль над ними с помощью цепочки эксплоитов ToolShell. Эксплуатируются при этом уязвимости CVE-2025-49704 и CVE-2025-49706, а также их исправленные версии CVE-2025-53770 и CVE-2025-53771.

Основные рекомендации по предотвращению таких вторжений сводятся к срочному обновлению уязвимых продуктов SharePoint либо к использованию антивирусов, которые способны детектировать эксплоиты ToolShell.

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

Наш эксперт Александр Родченко предлагает свой подход к детектированию атак на основе уязвимостей десериализации в среде CLR (таких как CVE-2025-53770). Вкратце, его идея звучит так:

– Подписываем ETW-монитор EDR-решения на ловлю попыток десериализации, то есть событий CLR: Loader.
– При получении такого события ищем подозрительные вспомогательные сборки: динамический Microsoft.GeneratedCode без пути и App_Web_toolpane.aspx* без пути.
– Если такие сборки найдены, сканируем память YARA-правилом для выявления опасных типов объектов (гаджетов), чьё поведение при десериализации может привести к выполнению вредоносного кода (LosFormatter и др.)

Подробности идеи и пример возможного YARA-правила смотрите в статье Александра. Знатоки .NET-архитектуры приглашаются оценить, оспорить или улучшить предложенный метод детекта.

Как ловить обфускацию? Зачастую в техниках обфускации Powershell можно встретить стандартные вызовы System.Text.Encoding и iex. Эти вызовы сами по себе не раскрывают полезную нагрузку — они лишь конвертируют/выполняют уже скрытый контент.

Основная цель атакующего — спрятать саму полезную нагрузку. Для этого может быть использовано шифрование/кодировка (Base64, AES и др.), разделение строки по частям и динамическая сборка, перемешивание/шифрование идентификаторов переменных.

Но при этом командлеты System.Text.Encoding и Invoke-Expression/iex остаются незамаскированными (см. пример на скриншоте). Это связано с тем, что обфускация их имён часто невозможна без изменения самого рантайма или без вызова по строкам, что усложняет код и добавляет вероятность ошибок.

Атакующий мог бы попробовать заменить Invoke-Expression на динамический вызов Invoke-Expression через & (call), New-Object System.Management.Automation.ScriptBlock::Create(...).Invoke(), или механизм Reflection. Но это также делает код громоздким и может нарушить политики безопасности (ConstrainedLanguageMode) либо поведение окружения (контекст исполнения, $ExecutionContext и др.).

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

Отсюда получаем рекомендации для защиты:

– Блокируйте выполнение таких небезопасных команд, как Invoke-Expression;

– Детектируйте строки такого вида:

$s = [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String("...")) 

iex $s

Мы знаем, что публикация больших исследований приносит больше лайков, чем маленькие полезные советы. Но мы ценим минимализм, а потому – очередной пост в жанре «хозяйке на заметку».

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

Злоумышленники использовали этот однострочник, чтобы загрузить файл с удаленного web-ресурса, сохранить его в скрытый файл .1, назначить ему права executable и запусить этот файл.

Мораль: надо следить за такими проявлениями минимализма, как создание и исполнение скрытых и односимвольных файлов, а также за подозрительными командами Python.

В больших AD-лесах админы часто «забывают» или ошибочно настраивают списки контроля доступа (ACL), не желая заморачиваться с чётким разделением и выдачей прав. В таких списках могут оставаться широкие разрешения для Everyone/Authenticated Users/Domain Computers, причём с расширенными правами на чувствительные объекты.

Это не мелочь: именно список DACL в nTSecurityDescriptor определяет, кто и что может делать с объектом. Но есть проблема: такие списки прав указаны для каждого отдельного субъекта (нет одной таблички), GUID’ы прав нечитабельны, а определения дескрипторов безопасности (SDDL) тяжело смотреть глазами.

Наш эксперт Александр Родченко написал утилиту ParseJsonWithSDDLs для решения этой проблемы. Основная идея: показать, какими правами обладают «все», то есть достаточно большой и потенциально неограниченный круг субъектов (анонимы, аутентифицированные пользователи, все ПК и т.д). Другими словами, утилита отвечает на вопрос: «Есть ли у нас в домене какие-то объекты, с которыми может сделать что-то любой пользователь?»

Функционал, реализованный в программе:

— парсит SDDL из nTSecurityDescriptor, вычленяет «широкие» ACE и показывает их в удобном виде (читаемые имена субъектов и объектов, декодированные GUID расширенных прав);
— умеет сама выгрузить весь лес и трасты в JSON (LDAP paging + SecurityDescriptorFlagControl для DACL), если у вас нет готовых экспортов ваших доменов; в некотором роде это работа SharpHound с опцией "вместе с DACL", но в данном случае автор сам реализовал это в коде;
— даёт HTML-сводку и при желании CSV для дальнейшей аналитики/хантинга.

Что даёт использование утилиты?

Это закрывает типовой класс конфиг-дефектов, про которые Microsoft годами пишет в своих рекомендациях по безопасности AD. Прогоны такой утилитой часто приносят «бесплатные» находки перед аудитами и пентестами. Примеры находок приведены на скриншотах выше:

(1) объект, который может изменить любой ПК — и никто не не знает, для чего это нужно; у клиента это был объект, относящийся к системе корпоративной печати,
(2) очень странный объект групповой политики — это заявка на повышение привилегий в домене,
(3) очень неправильно настроенные разрешения создавать общие папки: на самом деле, дали возможность создать объект-корень FTRoot (новый namespace) и создать под ним любые FTDfs-объекты — ссылки (на любой сервер) и их Target-списки.

Утилиту можно скачать в репозитории автора на Гитхабе — там же оставляйте отзывы и предложения по улучшению программы:
https://github.com/gam4er/DACLPlayground/tree/master