Один из самых популярных инструментов для реверса – программа IDA Pro от компании Hex-Rays. Наши эксперты из команды GREAT много лет использовали этот инструмент для анализа вредоносного ПО. И даже разработали собственный плагин hrtng, который значительно расширяет функционал IDA Pro – особенно в части анализа таких образцов, где используется обфускация и шифрование.

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

А как работает эта тулза, можно посмотреть на примере реверса хитрого вредоноса FinSpy. В этой истории плагин hrtng используется для расшифровки шеллкодов, для поиска хэшей имён API-функций в декомпилированном коде, с последующим восстановлением имён API-вызовов, а также для декомпиляции обфусцированного кода.

Время от времени мы проводим неформальные, но очень насыщенные встречи для тех, чьи интересы так или иначе затрагивают оффенсив (пентестеры, аппсекеры, аналитики). Эти митапы обычно состоят из трех-четырех докладов, после чего большинство участников перетекают в afterparty и живое общение.

О том, как попасть на очередное такое мероприятие, расскажем уже в следующем году. А пока – пример одного из докладов с последнего митапа: наш коллега Георгий Кигурадзе рассказал, как сдампить Lsass, оставаясь под радарами стандартных хантов. Было много запросов пошарить слайды этого доклада, и вот они – в приложенном файле.

TL;DR: Извлечение секретов из lsass – один из логичных шагов на этапе постэксплуатации в Windows-инфраструктурах. Однако большинство готовых решений гарантировано детектируется стандартными средствами. Наше решение: разработать свою реализацию дампа, на основе примитивов доверенного инструмента.

Основная идея в том, чтобы использовать прямое чтение физической памяти через подписанный Microsoft драйвер, который используется расследователями для снятия дампа оперативной памяти. Сканируя память, мы находим ядерную структуру EPROCESS для процесса lsass.exe. После парсинга этой структуры проходимся по всем VAD-ам, принадлежащим процессу, и ищем lsasrv.dll. Именно в этой библиотеке находятся необходимые нам ключи шифрования и контексты пользователей. Прочитав физическую память по нужным адресам, можно расшифровать контексты пользователей и получить их NTLM-хэши.

Всё это мы реализовали как BOF для Mythic C2 (про создание собственного Mythic-агента расскажем чуть позже).

Ну и полезный совет для стороны защиты: подобные атаки можно обнаружить по регистрации подозрительного драйвера для форензики (смотрите IoC на последнем слайде).

Современный автомобиль — это не только способ привлечь внимание противоположного пола. Это ещё и продвинутая компьютерная сеть, насчитывающая до сотни электронных блоков управления, связанных между собой через Controller Area Network (CAN).

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

Учитывая такие удивительные возможности, наши эксперты провели анализ защищённости системы инфотейнмента Mercedes-Benz Head Unit (MBUX). В работе использовали реальный автомобиль Mercedes B180, а также собственную платформу для тестирования аппаратного и программного обеспечения.

Обнаруженные в этих тестах уязвимости позволяют человеку, получившему доступ к стандартному USB-порту автомобиля, управлять медиа-системой MBUX по своему усмотрению. Например, владелец автомобиля может разблокировать некоторые платные функции, не заплатив за них.

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

Обо всех выявленных проблемах мы, конечно же, сообщили производителю. Подробности читайте в нашем отчёте "Обзор защищенности головного устройства Mercedes-Benz".

В середине января Belsen Group выложила в публичный доступ архив с файлами конфигурации и учётными данными для более 15 тысяч устройств FortiGate (межсетевые экраны производства Fortinet). Сама утечка произошла в конце 2022 года через уязвимость CVE-2022-40684, которая позволяет обходить аутентификацию в программном обеспечении FortiOS, FortiProxy и FortiSwitchManager.

Про эту утечку уже написали многие — но не написали, что делать. А между тем, слитый дамп может дать атакующим много ценной информации о потенциальных жертвах. Данные в архиве упорядочены по IP-адресам устройств (TLD-TARGET_IP), для каждого адреса там содержится файл конфигурации и учётные данные VPN с паролями в открытом текстовом виде.

Чтобы узнать, стали ли вы (или станете) жертвой атаки на основе этой уязвимости и последующей утечки, рекомендуем проделать следующие телодвижения:

(1) Проверить, есть ли адрес вашего устройства в списке скомпрометированных IP-адресов. Также стоит посмотреть список контактных почтовых адресов, которые найдены в слитых конфигах (вдруг ваш емейл там тоже засветился).

(2) Проверить наличие CVE-2022-40684 на ваших устройствах. Этой уязвимости подвержены FortiOS — версии от 7.2.0 до 7.2.1, версии от 7.0.0 до 7.0.6; FortiProxy — версии 7.2.0, версии от 7.0.0 до 7.0.6; FortiSwitchManager — версии 7.2.0 и 7.0.0. Уязвимость исправлена в версиях FortiOS 7.2.2 и выше, 7.0.7 и выше; FortiProxy 7.2.1 и выше, 7.0.7 и выше; FortiSwitchManager 7.2.1 и выше, 7.0.1 и выше.

(3) Выяснить, эксплуатировалась ли эта уязвимость на вашем устройстве. Для этого производитель советует провести аудит конфигураций и учётных записей. Особенно полезно посмотреть, появлялся ли в логах вашего устройства “User=Local_Process_Access”, а также проверить существование аккаунта 'fortigate-tech-support' с правами супер-админа (он создаётся атакующими, см. скриншот).

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

Метод обхода защитных средств под названием BYOVD (Bring your own vulnerable driver) заключается в использовании легитимного (но уязвимого) либо самописного драйвера с высокими привилегиями, который работает на уровне ядра ОС – что позволяет такому драйверу прерывать или подменять процессы, запущенные продуктами безопасности. Один из вариантов этой техники работает так:

– Атакующий находит легитимный драйвер, который при запуске создаёт в файловой системе файл с определенным именем (назовём его <driver_filepath>).
– Этот драйвер должен загружаться в boot-сектор раньше, чем драйвер продукта защиты.
– Определяется путь к процессу драйвера защиты (назовём его <sectool_filepath>).
– В файловой системе создаётся символическая ссылка (symbolic link) с именем <driver_filepath>, которая ведёт на драйвер продукта защиты <sectool_filepath>.
– При перезагрузке ОС, когда загружается легитимный драйвер, он должен обратиться для записи на адрес <driver_filepath>; однако символическая ссылка переадресует все модификации на адрес <sectool_filepath>; таким образом, метод позволяет перезаписать и повредить файл защитного продукта.

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

Нужно отслеживать создание ссылок на любые компоненты продуктов защиты:

1) Собираем события создания жестких (hard) ссылок штатными средствами операционки: 4664(S): An attempt was made to create a hard link.
2) Создание символических ссылок не логируется системой, поэтому используем EDR-like телеметрию.
3) При сборе командных строк или событий создания процессов иногда можно отловить создание ссылок по аргументам: 'mklink', 'New-HardLink', 'New-SymLink', 'symboliclink', ...

Летом наши эксперты расследовали целый ряд атак, основанных на эксплуатации уязвимости 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.

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