Вот, казалось бы, очень удобная фича: вы ещё не успели открыть присланный вам файл на своём компьютере, а 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-сети и заставить их вести себя непредсказуемо.

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

Утилита 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,
— контроль доступа приложений (белый список),
— сегментация и изоляция корпоративных сетей, чтобы не допустить горизонтальное перемещение в случае взлома.

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