Летом наши эксперты расследовали целый ряд атак, основанных на эксплуатации уязвимости CVE-2023-48788 в продуктах FortiClient EMS. Попробуем разобраться, как ловить подобные атаки по пост-активностям на хосте.

Суть атаки сводится к эксплуатации SQL-инъекции в контексте Microsoft SQL Server. Таким образом атакующий может применить любой удобный способ для выполнения команд ОС из запросов SQL, с последующей загрузкой своего вредоносного ПО. Одним из наиболее частых примеров является использование хранимой процедуры xp_cmdshell.

На что смотреть защитникам:

1) Включение xp_cmdshell. EventID 15457. Обязательно к включению. Везде.

2) Application лог MSSQL с EventID 15281 с фильтром на компонент xp_cmdshell. Там будут заблокированные попытки использования еще выключенного xp_cmdshell.

3) Смотреть в старты необычных процессов от MSSQL: cmd, powershell, lolbins, ... И конечно, поведение дочерних объектов, инициирующих внешние коммуникации. Такие активности на практике отлавливаются довольно часто, это могут быть:
3.1) дискавери (whoami, tasklist, net)
3.2) закрепление (schtasks)
3.3) дженерик-тактики с использованием cmd и powershell.

4) Ну и в целом, рекомендуем настроить ваши аудиты MSSQL на детектирование подозрительных активностей.

В анализе безопасности мобильных и веб-приложений одной из первых задач является сбор информации об API-эндпоинтах и о формате HTTP-запросов для взаимодействия с ними.

В случае с веб-приложениями можно найти доступную OpenAPI-спецификацию или извлечь данные о запросах из JavaScript-файлов. Однако для мобильных приложений эта задача усложняется: HTTP-запросы могут формироваться из множества внутренних классов, а сам код часто бывает обфусцирован.

Наш эксперт Сергей Бобров написал на основе jadx-декомпилятора утилиту BFScan, которая помогает решать такие задачи при анализе JAR/WAR/APK приложений. Скачать эту тулзу можно здесь:
https://github.com/klsecservices/BFScan

Утилита BFScan формирует сырые HTTP-запросы и OpenAPI-спецификацию по конфиг-файлам и аннотациям классов и методов. При этом поддерживаются как клиентские библиотеки (например, Retrofit), используемые в APK для взаимодействия с бэкендом, так и серверные технологии, такие как Spring-аннотации. Это облегчает тестирование API в тех случаях, когда тело HTTP-запроса необходимо сформировать из множества вложенных классов.

Дополнительно BFScan анализирует строковые константы в Java-классах и ресурсах приложения для поиска строк, похожих на URL, пути или захардкоженные секреты.

Пример работы утилиты с классом, использующим Spring-аннотации:

@RestController
@RequestMapping("/api")
public class UserController {

    @PostMapping("createUser")
    public String create(@RequestParam Optional<String> someParamName, @RequestBody User user) {
        return "response";
    }

В результате утилита формирует такой запрос:

POST /api/createUser?someParamName=value HTTP/1.1
Host: localhost
Connection: close
Content-Type: application/json

{
  "name": "name",
  "age": 1
}

Утилиту BFScan удобно использовать как для анализа клиентских мобильных приложений, так и в случае, если вы получили скомпилированный JAR/WAR от серверного приложения, для поиска в нём захардкоженных секретов или дальнейшего анализа API-эндпоинтов, которые обрабатываются в приложении.

А если приложение обфусцировано, то используя jadx, можно легко сформировать mapping-файлы для переименования обфусцированных классов и корректного формирования HTTP-запросов.

В прошлом году в популярной программе для виртуализации Parallels Desktop для Mac OS на базе процессоров Intel была найдена уязвимость CVE-2024-34331, позволяющая запускать вредоносные файлы с высокими привилегиями.

Уязвимость связана с отсутствием проверки подписи в ходе выполнения сценария repack_osx_install_app.sh. Это даёт возможность атакующему запустить утилиту createinstallmedia с правами root без проверки принадлежности файла к дистрибутиву macOS.

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

Подробности о том, в чём состоит уязвимость CVE-2024-34331 и почему её не смогли исправить сразу – читайте в новой статье Дмитрия Лифанова. А мы здесь процитируем только выводы: как ловить такую атаку в вашей инфраструктуре? Нужно отслеживать:

– Попытки открытия файлов через консоль с использованием Parallels Desktop. Команда может выглядеть, например, так: “open /tmp/proof.app -a /Applications/Parallels Desktop.app”. Таким способом атакующий может вызвать сценарии переупаковки, не дожидаясь легитимного запуска от пользователя.
– Создание символьных ссылок на объекты, расположенные в пользовательских каталогах и tmp-каталогах.
– Действия над файлами createinstallmedia, boot.efi, systemversion.plist, platfromsupport.plist и basesystem.dmg, которые не связаны с дистрибутивом macOS Install OS X и самой системой.
– Активности, связанные с использованием переменных DYLD_* с целью загрузки подозрительных динамических библиотек. В частности, DYLD_INSERT_LIBRARIES позволяет произвести загрузку динамической библиотеки в процессе выполнения приложения, а DYLD_LIBRARY_PATH позволяет переопределить путь поиска динамических библиотек.
– Загрузку подозрительных динамических библиотек в процесс, например, с использованием события ESF ES_EVENT_TYPE_NOTIFY_MMAP.
– Создание директорий и файлов в них, содержащих в пути .app, похожих на приложение и его контент, но расположенных в нетиповых локациях для приложений и пакетов.

Традиционный недостаток котиков в нашей ленте мы традиционно компенсируем выпуском годовых аналитических отчётов наших команд, которые занимаются мониторингом (MDR) и реагированием на инциденты (IR).

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

IR Report 2024 // MDR Report 2024

А кто хочет послушать комментарии наших экспертов по этой аналитике или даже задать им каверзные вопросы – приходите на вебинар 3 апреля в 11:00 МСК:
https://www.kaspersky.ru/go/ru-mdr-report-2024

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

А теперь представляем вашему вниманию вторую часть исследования безопасности интерфейсов MS-NRPC. В этом материале наш эксперт Хайдар Кабибо объясняет, почему Windows допускает такие небезопасные действия, и как детектировать подобные атаки. В частности:

– Групповая политика "Restrict Unauthenticated RPC Clients" в теории могла бы быть использована для контроля таких активностей. Но на практике, даже при установке этой политики в режим "Authenticated" атакующие всё равно могут использовать небезопасные функции MS-NRPC-интерфейса. В случае выбора режима "Authenticated without exceptions" сбор данных о домене без авторизации будет заблокирован – но такая политика одновременно вырубает некоторые функции доменного контроллера.

– Детектировать сбор данных о домене можно с использованием системы Event Tracing for Windows, которая логирует события, связанные с RPC. Однако такой способ даёт большой поток событий по RPC-активностям, и среди них трудно выловить нужные.

– Для детектирования атаки можно применить инструмент с открытым кодом RPC-Firewall. Эта тулза мониторит все удаленные RPC-вызовы, позволяя фильтровать их по адресу источника, и при необходимости блокировать (см. скриншот). Правда, это сторонний инструмент.

Остальные подробности анализа безопасности MS-RPC-интерфейсов – в полной версии исследования Хайдара.

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

Однако эта же фича может быть использована для кражи учётных данных, благодаря уязвимости CVE-2025-24071. Атакующий может создать вредоносный файл .library-ms со ссылкой на контролируемый SMB-сервер, поместить файл в RAR/ZIP-архив и направить жертве (см. скриншот).

Поскольку формат .library-ms является доверенным для Windows Explorer, после распаковки из архива система автоматически парсит и индексирует такой файл. Здесь и срабатывает вредоносная ссылка, что приводит к попытке NTLM-авторизации на целевом узле. В результате атакующий может получить NTLM-хэш жертвы – и далее использовать для своих целей.

О том, как детектировать подобную атаку, рассказываем в отдельной статье.

В ходе недавнего расследования инцидента у одного из клиентов в Бразилии наши эксперты столкнулись с ботнетом Outlaw (Dota), который автоматически распространяется по Linux-системам, использует IRC-каналы для связи с C2 и различные техники закрепления, а в качестве основной творческой деятельности занимается криптомайнингом.

Этот вредонос был впервые замечен ещё в 2018 году. С тех пор Outlaw многократно возвращался с новыми фичами – например, он научился убивать чужие криптомайнеры на захваченных машинах. Ботнет находит новые жертвы по всему миру, включая Китай и Тайвань, США и Канаду, Ирландию и Германию, Таиланд и Сингапур. Теперь вот добрался и до Бразилии.

Подробное описание расследования можно прочитать в отдельной статье. А здесь отметим, что тактика начального доступа у ботнета Outlaw достаточно проста: он подбирает пароли к SSH-серверам.

Потому и методы защиты тоже просты. Нужно использовать SSH-авторизацию по ключу (а не по паролю), а также установить ещё несколько полезных настроек в файле /etc/ssh/sshd_config :

Port <custom_port_number> (меняем дефолтный SSH-порт, куда долбят сканеры)
Protocol 2 (используем более защищенную версию протокола)
PermitRootLogin no (запрещаем рутовому пользователю логиниться по SSH)
MaxAuthTries <integer> (ограничиваем число попыток авторизации за сессию)
LoginGraceTime <time> (ограничиваем время в секундах для завершения логина)
ClientAliveInterval <time> (ограничиваем интервал для проверки активности сессии)
ClientAliveCountMax <integer> (ограничиваем число сообщений для таймаута)
PasswordAuthentication no (запрещаем авторизацию по паролю)
PermitEmptyPasswords no (запрещаем логин с пустым паролем)
PubkeyAuthentication yes (разрешаем авторизацию по публичному ключу)
X11Forwarding no (запрещаем удаленный запуск графических приложений)
PermitUserEnvironment no (запрещаем передачу переменных окружения)
Banner /etc/ssh/custom_banner (настраиваем приветствие при входе в систему)

Кроме того, рекомендуется отключить неиспользуемые протоколы авторизации:
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no

А также отключить возможности SSH-туннелирования:
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no

И наконец, ограничить доступ к SSH отдельными IP-адресами или подсетями:
AllowUsers *@10.10.10.217
AllowUsers *@192.168.0.0/24

Помимо всего этого харденинга через config, дополнительную защиту от брутфорса SSH-паролей дают такие полезные инструменты, как Fail2Ban и firewalld.

Нас часто спрашивают, почему канал называется «Фиолетовый сдвиг». Это потому, что всестороннее понимание безопасности невозможно без взгляда на системы с разных точек зрения — как со стороны защиты (blue team), так и со стороны нападения (red team). Ну а когда вы находитесь между красными и синими, вы начинаете видеть мир в фиолетовом спектре.

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

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

Подробности читайте в материале Олега Сенько: в первой части проводится сравнительный анализ различных фреймворков, а вторая часть рассказывает, как строится Mythic-агент и как он помогает решать задачи пентестеров.

Хотя одноплатные компьютеры часто называются как фруктовые пироги (Raspberry Pi, Banana Pi, Orange Pi), они популярны не только среди голодных школьников. Одноплатники применяются в самых разных сферах - например, это мощный инструмент в арсенале пентестеров и "красных команд".

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

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

Подробности - в докладе "Приключения red team в безопасности SBC", который состоится на конференции PHDays 22 мая в 11 часов.

Некоторым кажется, что главная задача проекта по анализу защищенности - впечатлить заказчика списком уязвимостей в его инфраструктуре. Должны ли пентестеры делать что-то ещё?

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

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

На таких жизненных примерах в докладе «Эффектный не равно эффективный» наш аналитик Ольга Зиненко покажет, из чего складывается эффективный пентест (PHDays, 22 мая, 11:10).

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

Как это выглядит: зараженный контейнер сканирует Интернет в поисках открытых Docker API и эксплуатирует их, создавая новые вредоносные контейнеры и заражая существующие. Те, в свою очередь, превращаются в новых "зомби", которые добывают криптовалюту и распространяют инфекцию дальше. Доставка происходит без участия командного сервера — зараженные системы автоматически инфицируют новые, что приводит к экспоненциальному росту числа "зомби".

Подробности расследования читайте в статье нашего эксперта Амжеда Ваги. В том же материале даны индикаторы компрометации и описание двух вредоносных инструментов атаки: это контейнерный червь под названием nginx (да, он маскируется под легитимный веб-сервер) и криптомайнер Dero.

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

Для запуска эпидемии злоумышленники использовали доступ к активной контейнеризованной инфраструктуре через Docker API, открытый в Интернет и не защищенный должным образом. Дальше контейнерный червь распространяется самостоятельно, но тем же способом.

Поэтому наши рекомендации по защите таковы:

— не публикуйте Docker API в Интернете, используйте VPN для удалённого администрирования;

— при необходимости доступа по HTTP защищайте Docker через TLS-авторизацию, которая будет давать доступ только клиентам с подписанными сертификатами (см. детали здесь);

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

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

Но что если SOC нашел legacy-систему без документации? Надо проанализировать архитектуру, выявить возможные вектора атак, покрыть релевантными детектами. А если таких нестандартных систем — не одна, а десять? Правильный подход к мониторингу источников известен, но на практике он требует много времени и глубокого понимая системы.

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

Аномалии аутенификации:
— Brute Force
— Password spraying
— Sharing creds
— The first logon to host (+ неуспешные попытки)
— The first logon from host (+ неуспешные попытки)
— Отслеживание профиля приложения клиента, которое использовалось для логина: отпечаток браузера для web, SQL-клиент для БД, толстый клиент для приложений и т.д. (вне профиля = алерт).

Манипуляции с привилегиями:
— Добавление/исключение в группу/из группы
— Изменение прав доступа
— Массовая блокировка/отключение администраторов
— Создание УЗ

Сеть:
— Изменение количества peer-ов
— Использование нетипичных для системы сетевых сервисов

Процессы и настройки:
— Выгрузка защищаемых ресурсов вне профиля
— Резервное копирование вне профиля
— Управление резервным копированием вне профиля
— Администрирование функций безопасности
— Удаление журналов аудита безопасности

Используя подобный подход, можно покрыть 11 из 14 тактик атак MITRE, что очень неплохо для незнакомой системы.

Более подробно о таких универсальных приемах Threat Hunting — слушайте завтра в докладе нашего эксперта Николая Советкина «Стандартные правила для нестандартных источников» на конференции PHDays (23 мая, 12:15). Для тех, кто не сможет присутствовать – обещают и трансляцию, и запись.

Как известно, лучший способ избежать эксплуатации уязвимости – поскорее накатить патч. Однако на практике многие не спешат с обновлениями. Поэтому наши специалисты по выявлению угроз ведут на Гитхабе свой список активных уязвимостей, которые встречаются на практике. Там же есть рекомендации, как обнаружить и предотвратить атаки, связанные с этими уязвимостями

Например, в апреле и мае была очень популярна эксплуатация десятибальной, то есть очень критической уязвимости CVE-2025-32433, которой подвержены SSH-сервера на основе библиотеки Erlang/OTP (Open Telecom Platform). Эта ошибка в обработке сообщений протокола SSH позволяет неавторизованным атакующим отправлять SSH-сообщения до авторизации, а затем выполнять произвольный код с привилегиями SSH-демона. Получив контроль над устройством, злоумышленник может красть конфиденциальные данные, шифровать инфраструктуру или использовать устройство для DoS-атак. Общедоступные эксплоиты для RCE появились сразу после обнародования уязвимости в апреле.

Казалось бы, проблема легко устраняется обновлением Erlang/OTP до исправленной версии (OTP-27.3.3 и выше, OTP-26.2.5.11 и выше, OTP-25.3.2.20 и выше). Однако обновление происходит небыстро, поскольку зачастую это оборудование телекомов, IoT и других систем высокой доступности. На платформе Erlang/OTP работают многие устройства Cisco, Ericsson, Schneider Electric, Broadcom и других компаний.

Что делать для предотвращения атаки, если не довелось сразу обновиться:

- Отключить уязвимый SSH-сервер или запретить к нему доступ правилами фаервола. Уязвимыми являются все версии OTP до вышеупомянутых.

- Анализировать входящий трафик уязвимого SSH-сервера: признаком атаки является получение сообщения SSH_MSG_CHANNEL_OPEN или SSH_MSG_CHANNEL_REQUEST до получения от сервера сообщения SSH_MSG_USERAUTH_SUCCESS.

Ну и на будущее, чтобы быть в курсе подобных угроз и методов защиты от них – подписывайтесь на наш репозиторий Active Vulnerability List.

Одна из проблем, которые мы встречаем в проектах по оценке компрометации: сервис-провайдеры (MSP/MSSP) не уделяют достаточного внимания аудиту событий клиента, что приводит к пропущенным инцидентам.

В ходе одного такого проекта наши эксперты проверили журналы антивирусов и обнаружили несколько случаев детектирования веб-шелла на одном сервере в течение нескольких дней. При этом SOC-аналитики сервис-провайдера не подняли тревогу, потому что антивирус каждый раз удалял вредоносное ПО (см. скриншот).

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

Больше таких примеров, а также общие принципы Compromise Assessment – в записи вебинара Виктора Сергеева «Вне зоны видимости: как выявить и устранить скрытые киберугрозы».

Рассказывая про зомби-эпидемию в контейнеризированных средах, мы советовали не выставлять открытый Docker API в Интернет, а также вести проактивный поиск угроз в контейнерных инфраструктурах.

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

Однако наши эксперты знают, как найти точку начала атаки на основе анализа логов хоста. Вот некоторые принципы:

— Чтобы узнать, что процесс запущен внутри контейнера, достаточно убедиться, что родительским процессом для него является runc (при запуске в интерактивном режиме) или shim (при запуске в фоновом режиме).

— Аргументы командной строки родительского процесса (shim или runc) позволяют определить целевой контейнер, в котором запущен подозрительный процесс.

— Определённые события, которые являются нормальным поведением в среде Linux, должны вызывать подозрение, если они выполняются внутри работающего контейнера. Так, установка Docker CLI может быть приемлемой для хоста, но не для контейнера.

— Необходимо внимательно расследовать случаи появления нестандартного для данной ОС процесса оболочки. Например, запуск процесса оболочки BusyBox был бы нетипичным в системе Debian или RedHat.

Подробности и боевые примеры — в новой статье Амжеда Ваги.

А помните, мы рассказывали, как злоумышленники могут без авторизации производить перебор доменных пользователей через интерфейс 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.