Предполагается, что Windows Defender, или Защитник Windows, должен защищать пользователей OC Windows от вредоносных программ. Неудивительно, что злоумышленники ищут способы вырубить этот встроенный антивирус.

В 2025 году появилось несколько новых атак, позволяющих это сделать. Летом мы рассказывали о техниках с использованием уязвимого драйвера (BYOVD). А осенью исследователи из Zero Salarium обнародовали метод отключения Windows Defender без всякого дополнительного ПО — через символическую ссылку (symlink).

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

Windows Defender хранит свою исполняемую часть в такой папке:

%PROGRAMDATA%\Microsoft\Windows Defender\Platform\[номер_версии] 

Каждый раз, когда Defender обновляется, создаётся новая подпапка с номером версии, и служба Defender запускается именно из неё.

Прав Администратора недостаточно для создания и изменения файлов в директориях Defender, в том числе и в директории Platform. Однако администратор может в ней создать другую папку. А также создать символическую ссылку на подконтрольную директорию.

Это приведёт к тому, что после успешной подмены пути Defender начинает использовать файлы из папки под контролем атакующего, что позволяет:

— внедрять свои библиотеки (DLL sideloading);
— исполнять произвольный код в контексте службы Defender;
— изменять или удалять исполняемые файлы Defender;
— просто ломать работу Defender (удаление символической ссылки делает невозможным запуск службы MS Defender).

Проще говоря, злоумышленник может полностью нейтрализовать или контролировать Defender без использования каких-либо сторонних инструментов. Для этого ему нужно:

1) Скопировать последнюю версию Defender из Platform в другую папку — допустим, в C:\temp\999

2) В каталоге Platform создать символическую ссылку с именем, соответствующим более поздней версии (например, для текущей версии 4.18.25020.1009-0 дать название 5.18.25020.1009-0). Для этого выполнить команду:

mklink /D "C:\ProgramData\Microsoft\Windows Defender\Platform\5.18.25020.1009-0" "C:\temp\999"

3) Перезагрузить Windows.

После перезагрузки будет использоваться якобы новая версия Defender, обновятся абсолютные пути в реестре, которые через символическую ссылку будут указывать на директорию C:\temp\999. Удаление этой ссылки приведет к тому, что Defender перестанет запускаться.

Как защищаться:

Поскольку создание символических ссылок не логируется системой, нужно выявлять их создание, отлавливая командные строки с аргументами mklink, New-SymLink, symboliclink и директорией \Windows Defender\Platform\

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

И зря. Если внимательнее изучить дополнительные данные, можно обнаружить, что на самом деле был запущен инструмент для туннелирования, который замаскирован под системный процесс. Подозрение аналитика должны были вызвать такие действия, как переименование процесса и его размещение в папке system32.

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

А вот другой пример: некое правило детектирования часто даёт ложноположительные срабатывания (FP). Привыкнув к этому, аналитик SOC закрывает очередной алерт, не проявив к нему должного внимания... а это была реальная атака.

Это ещё одно известное когнитивное искажение, которое свойственно рассуждениям по аналогии. Оно тоже закреплено в народной культуре – в виде истории про мальчика, который слишком часто кричал в шутку "волки, волки!"

Наш коллега, аналитик SOC Таха Хаким, собрал в своей статье примеры таких стереотипов мышления и «слепых пятен», характерных для специалистов по кибербезу. А также предложил ряд методов, позволяющих аналитикам выявлять подобные предубеждения и косяки в своей логике.

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

Подробнее – в статье "Human factor in cyber defense: when the enemy is our own mindset"

Фреймворк Mythic остаётся одним из ключевых инструментов в арсенале пентестеров. Модульная архитектура, контейнерный деплой и удобный веб-интерфейс делают его практичным выбором для операций Red Team. В наших предыдущих постах мы уже разбирали тонкости этого фреймворка, от развёртывания до OPSEC-нюансов.

Защитники тоже знают Mythic не понаслышке: его артефакты достаточно характерны, чтобы выстраивать эффективное детектирование. Исторически агенты Mythic чаще выходят в сеть по каналам HTTP(S). Это универсально, но предсказуемо: современные средства защиты, от TLS-инспекции до поведенческого анализа, хорошо ловят подозрительный веб-трафик.

В частности, наши коллеги недавно опубликовали подробный разбор сетевых признаков Mythic с конкретными паттернами и артефактами в трафике; по сути, это готовое настольное руководство для SOC-аналитиков.

Но что если перейти на другой транспорт? Поддержка TCP даёт пространство для маневра. Вместо HTTP-заголовков и типовых TLS-рукопожатий получаем L4-сессии с настраиваемым фреймингом.

Однако надо помнить, что это не «невидимость», а другая поверхность детектирования. Веб-паттерны исчезают, но остаются признаки на egress-контролях и по L4-поведению. Плюс появляется возможность тонко настраивать протокол обмена, удерживать устойчивые сессии для туннелирования и снижать задержки при выполнении команд.

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

Важно: TCP в случае Xenon используется прежде всего как P2P/Link-транспорт внутри сети; внешний egress в большинстве сценариев по-прежнему обеспечивает агент HTTP/WS.

Что делать защите?

Для синей команды переход Mythic на TCP-транспорт — это сигнал обновить методологию.

Рекомендуем:
— пересмотреть правила мониторинга сетевого трафика,
— добавить корреляции между сетевыми соединениями и активностью процессов,
— проверить применение egress-политик в сегментах без веб-прокси,
— расширить охоту по L4-поведению.

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

В декабре 2025 года были обнаружены две уязвимости CVE-2025-59718 и CVE-2025-59719 для обхода аутентификации в продуктах Fortinet с использованием механизма single sign-on (SSO) и учетной записи FortiCloud. Эти уязвимости позволяли атакующим пройти аутентификацию с помощью специально подготовленного SAML-пакета, который отправляется в FortiOS, FortiWeb, FortiProxy, или FortiSwitch Manager, если на устройстве включен функционал SSO.

Аналогичные атаки с обходом SSO-аутентификации наблюдались у клиентов Fortinet и в январе. Это была уже новая уязвимость CVE-2026-24858, и она тоже позволяла злоумышленнику с учёткой FortiCloud логиниться в чужие аккаунты FortiOS, FortiManager, FortiAnalyzer, FortiProxy и FortiWeb.

Как защищаться:

Компания Fortinet отключила аутентификацию через FortiCloud SSO для уязвимых версий продуктов. Клиентам рекомендуется обновить эти продукты до исправленных версий, тогда SSO- аутентификация снова заработает. Можно и самостоятельно отключить SSO в ваших продуктах – на случай, если вскоре найдётся и четвёртая уязвимость того же рода.

Попытки эксплуатации можно детектировать по индикаторам компрометации, включающим учётные записи FortiCloud, которые использовались для атак, а также IP-адреса злоумышленников и учетные записи, которые создавались в случае успешной атаки с целью закрепления.

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

С продуктов Fortinet можно собирать телеметрию для детектирования этой вредоносной активности:
— данные по учетной записи, IP-адресу и методу аутентификации есть в событиях аутентификации (FTNTFGTmethod=sso или method=sso),
— информацию о создании административной учетной записи (msg=”Add system.admin …”),
— информацию об экспорте конфигурации (msg=”System config file has been downloaded by user …”).

А ещё в январе, почти одновременно с атаками на Fortinet, злоумышленники скомпрометировали другой ИБ-продукт: вредоносное ПО распространялось через сервер обновлений антивируса eScan. Мораль: мониторить нужно все продукты, включая и те, что призваны обеспечивать безопасность.

Февраль в ИБ начался с громкой истории о компрометации инфраструктуры обновлений популярного редактора Notepad++. Злоумышленники в течение нескольких месяцев имели доступ к центру обновлений Notepad++ и раздавали оттуда кастомное вредоносное ПО специально выбранным жертвам.

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

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

Наши коллеги выпустили подробный разбор цепочек атак на основе заражённых обновлений Notepad++. В той же публикации можно найти большой список индикаторов компрометации. В первую очередь рекомендуется:

— проверить, использовался ли в ваших системах инсталлятор NSIS, который применялся на первом этапе во всех указанных атаках; выявить это можно по системным логам, показывающим создание директории %localappdata%\Temp\ns.tmp,
— поискать в логах сетевого трафика обращения к сервисам на экзотическом домене temp[.]sh. Это очень нетипичное поведение для корпоративных систем, зато очень типичное для обращений к С2, которые использовались в данных атаках.

Что ещё может увидеть SOC?

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

А для выявления именно этой атаки с подменой обновлений Notepad++ рекомендуем:

— Проверить, обращался ли процесс gup.exe (обновлятор Notepad++) к нетипичным адресам, помимо notepad-plus-plus.org, github.com и release-assets.githubusercontent.com. Любые другие домены или IP в запросах обновления — это тревожный сигнал.
— Если есть соответствующие журналы, можно проверить, что именно качал и запускал gup.exe. Появление процесса-ребёнка gup.exe с именем update.exe или AutoUpdater.exe, тем более во временной папке пользователя — явный индикатор атаки.

Как вы могли заметить, наши "красные" регулярно создают полезные инструменты (BFScan, UnUnicode, Collab2, osmo-nidc, разные штуки для Mythic). Вот и сегодня расскажем, как мы улучшили работу с модулем Hive для коллаборации пентестеров на платформе Hexway Pentest Suite.

Приложение Hive позволяет собирать в одном месте результаты сканов, заметки, скриншоты и другую инфу о сервисах. А ещё мы используем Hive для того, чтобы отслеживать план работ: отмечать, что уже проверено, на что стоит обратить внимание, и кто из команды какой сервис смотрит сейчас. Это позволяет не выполнять проверки дважды (или больше раз, если в проектной команде много пентестеров и каждый хочет запустить условный ffuf со словарем raft-large-directories-lowercase.txt), а также фильтровать сервисы по статусам.

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

У компании Hexway есть библиотека на Python для работы с Hive REST API, но она давно не обновлялась. Однако в документации описано, как получить спецификацию OpenAPI.

В итоге мы написали утилиту scan2hive, которая парсит результаты работы разных инструментов и загружает в Hive. Вот что делают её модули:

HTTPX. Парсит результат httpx в формате JSON, добавляет к портам тег и заметку вида:

httpx result:
url: {url}
title: {title}
webserver : {webserver}
tech: {tech}
final_url: {final_url}

Удобно пролистывать список портов и сразу понимать, что это за сервис. Для поиска можно использовать фильтр по заметке, например, note == '%nginx%'.

Nmap. Модуль для импорта результатов nmap и masscan (формат XML). В веб-интерфейсе Hive есть возможность импорта файлов с результатами работы этих утилит, но мы добавили несколько фич:

— Если на хосте больше 300 портов (можно число задать параметром -m), то порты не импортируются (используем для отсетивания false positive) и к IP-адресу добавляется заметка:

  if len(host.ports) > self._max_ports:
    host.notes.append(HiveLibrary.Note(text=f"{len(host.ports)} ports. No port will be imported"))
    logger.info(f"Host {host.ip} has {len(host.ports)} open ports. Skip ports.")
    host.ports = list()

— К каждому порту добавляется тег.
— Результаты скриптов можно добавить в заметки или проигнорировать их (параметр --script-parsing). По умолчанию данные добавляются в Records, как и при импорте из веб-интерфейса.

Nuclei. Из формата JSON или JSONL забирает template_id, severity (можно указать параметр --min-severity), description, extracted_results, matched-at и matcher-name и добавляет заметку к порту (по одной заметке на severity). Можно игнорировать часть шаблонов.

Gowitness. Может импортировать скриншоты (по умолчанию без скринов, можно выбрать все или только для ответов 200 ОК) и добавлять заметку с данными из базы:

gowitness result:
url: {url}
response_code: {response_code}
title: {title}
webserver : {webserver}
final_url: {final_url}
tech: {tech}
cookies: {cookies}

Poseidon. Парсит json с результатом таски в агенте poseidon C2 Mythic.

В теге мы обычно указываем IP, с которого обращались к хостам, что помогает составить карту сети на внутреннем пентесте или, например, понять, что какие-то сервисы доступны только из конкретной страны. Для того, чтобы проверить, как распарсится файл, можно использовать режим --dry-run, а для загрузки в Hive использовать режим --upload.

А в /tests мы добавили сгенерированные скриптом результаты сканов nmap и masscan, чтобы не тестировать на данных заказчиков.

Говорят, импортозамещение идёт полным ходом: за 2025 год доля отечественных систем управления ресурсами предприятия (ERP) на российском рынке достигла 75%. И основную часть этих ERP-проектов (около 80%) составляют решения компании 1С.

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

При этом оказывается, что компрометация серверов 1С не требует особо сложных техник: атакующие используют тривиальные ошибки в настройках. Вот некоторые примеры:

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

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

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

Причина: для пользователя настроена аутентификация средствами 1С, однако при создании учетки поле Password оставлено пустым. Поэтому вход в систему для такого пользователя осуществляется с пустым паролем, то есть без пароля вообще (см. скриншот).

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

Об этих и других опасных косяках в настройке 1C, а также о том, как исправить их, пока вас не поломали — читайте в статье Алины Сухановой "По следам реальных атак: как можно было избежать компрометации 1C".

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

После получения повышенных привилегий на хосте злоумышленники установили Velociraptor, указав в server_urls свой C2-сервер. С этого момента дальнейшее управление системой осуществлялось уже через него.

После базового Discovery они скачали Visual Studio Code (Insiders) и установили VS Code Tunnel в режиме Install as a service. Важно понимать, что под капотом это не «настоящий сервис», а запись в Run-ключе:

HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Run

Далее — ещё немного Discovery, но уже через VS Code Server, и следующим шагом появляется Cloudflare Tunnel.

Однако и этого атакующим оказалось недостаточно: финальным штрихом стал Zoho Assist в режиме Unattended Remote Session, позволяющий подключаться к системе без какого-либо подтверждения со стороны пользователя.

Итог: четыре независимых канала удалённого доступа к одному хосту. При этом три из них — Velociraptor, VS Code Tunnel\Server и Zoho Assist — встречаются не так уж часто.

Что здесь можно детектировать?

— Velociraptor. Если вы его не используете, любое появление этого сервиса уже будет красным флагом. А если используете — контролируйте список допустимых серверов, так как обращения к посторонним server_urls выглядят крайне подозрительно.

— VS Code Tunnel. Обращайте внимание на установку сервиса, будут примерно такие команды:

    code-insiders.exe tunnel --accept-server-license-terms service install
    code-tunnel.exe tunnel service uninstall 

Также смотрите на Run-ключ:

    key: Visual Studio Code - Insiders Tunnel
    value: ...\code-insiders.exe --verbose --cli-data-dir C:\Windows\system32\config\systemprofile\.vscode-insiders\cli tunnel service internal-run --log-to-file C:\Windows\system32\config\systemprofile\.vscode-insiders\cli\tunnel-service.log

И ещё обращайте внимание на активность от процессов VS Code Server, расположенных по пути .vscode\cli\servers\ или .vscode-insiders\cli\servers\.

— Cloudflare Tunnel. При старте/остановке сервиса и запуске туннеля генерируется EventID: 1 в журнале Application (Source: Cloudflared) — это удобная точка для алертов.

— Zoho Assist. Для его использования в режиме Unattended требуется запуск сервиса Zoho Assist – Unattended Support, реализованного в файле ...\ZohoMeeting\UnAttended\ZohoMeeting\ZohoURSService.exe.

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

В одном из инцидентов злоумышленник модифицировал конфигурацию веб-сервера Apache так, чтобы все запросы, поступающие на URL-адрес https://[имя домена]/proxy/tunnel, проксировались на внутренний адрес 127.0.0.1:8080, с использованием протокола WebSocket Secure. Данный протокол предоставляет двунаправленную шифрованную связь между клиентом (атакующим) и сервером. Содержимое файла конфигурации веб-сервера Apache выглядело так:

<VirtualHost *:443>
    ...
    <Location "/proxy/tunnel">
         ProxyPass "wss://127.0.0.1:8080"
     </Location>
</VirtualHost>

А на порту 8080 для создания канала связи злоумышленник запустил утилиту chisel в качестве сервера, ожидающего входящих соединений, с параметром –reverse.

Эти действия позволили злоумышленнику создать туннель и получить доступ к внутренней инфраструктуре, маскируя сетевую активность под легитимный шифрованный HTTPS-трафик.

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

Для обнаружения подобных способов создания туннеля необходимо:

— отслеживать изменения файлов конфигурации веб-сервера Apache и проверять их на наличие строк «ProxyPass» и «wss://»,

— мониторить запуски процессов с подозрительными аргументами (например --reverse, --socks5),

— выявлять в журналах веб-приложений аномальное количество обращений к URL-адресам, не предусмотренных в логике веб-приложения.

Также рекомендуется размещать публично доступные серверы в отдельном сегменте (DMZ) и мониторить активность на них средствами EDR.

Как вы наверняка помните, недостаток котиков в нашей ленте мы обычно компенсируем другими животными — из ежегодных отчётов наших команд MDR и Incident Response (2023 год, 2024 год).

Аналогичная статистика по инцидентам 2025 года тоже вскоре будет опубликована. Однако в этом году защитники прав животных попросили нас не изображать рептилий в качестве угроз. Поэтому в новых отчётах нам придётся впечатлять вас голой аналитикой.

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

В частности, на диаграмме выше показано количество человекоуправляемых атак в разных сферах. Можно заметить всплеск таких атак на Госсектор и Телекомы в 2021 году. А в 2022 году сильно досталось средствам массовой информации — при том, что в 2020 и 2021 годах интерес атакующих к СМИ отсутствовал вовсе.

Однако следует ещё раз уточнить, что данный график отражает только один тип атак — но есть и другие. Так, в 2025 году значительно выросло число критичных инцидентов типа «социальная инженерия» в таких отраслях, как СМИ, Госсектор и Финансы. А поскольку за успешным фишингом обычно следуют более разрушительные типы атак, мы получаем очень неутешительный прогноз для этих отраслей.

Подробности о распределении других критичных инцидентов по отраслям, а также гипотезы о том, почему они так распределялись — смотрите в статье "История критичных инцидентов".

За последние несколько лет рынок наполнился огромным количеством новых процессорных чипов из Поднебесной — в частности, на базе стандарта RISC-V, со своими собственными реализациями ядер и расширениями.

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

Поэтому пришлось:

— пройти квест по определению, что это за инструкции; оказалось, что они относятся к расширению P Extension (оно же Packed SIMD Extension);

— на основе раннего черновика спецификации P Extension написать декодер для этих инструкций и подружить его с IDA Pro;

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

Подробности этого приключения по улучшению инструментария — в статье "От скалярной тоски к SIMD-эйфории: как подружить IDA Pro с инструкциями RISC-V P Extension".

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

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

Один из способов обнаружить ноды — найти, какие хосты используют SSL-сертификат с common name Kubernetes Ingress Controller Fake Certificate. Например, это можно сделать с помощью скрипта для nmap ssl-cert.

На одном из проектов мы нашли таким способом 47 нод. И по некоторым хостнеймам и подсетям сделали вывод, что кластер не один. Но как узнать, какие сервисы запущены в этих кластерах?

Благодаря использованию одного места для сбора всей информации, мы выяснили, что у нас уже есть учётные данные пользователя с привилегией sudo на этих хостах после успешной атаки Password Spray.

В директории /etc/kubernetes/ на мастер-ноде был конфиг не только самой ноды, но и администратора кластера, что позволило не тратить время на повышение привилегий.

Так как Kubernetes API доступен был только на localhost мастер-ноды, использовали опцию -D при подключении по SSH к ноде, и с конфигом администратора кластера получили полный доступ к API. А затем собрали всю необходимую информацию о кластере K8s, добавив опцию для игнорирования недоверенного сертификата и переменную окружения для работы через прокси:

export KUBECONFIG=~/admin.conf
HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --insecure-skip-tls-verify=true cluster-info

Список нод поможет оценить размер кластера и отметить хосты, которые к нему относятся:

kubectl get nodes -o wide

По названиям неймспейсов можно попытаться понять, какие сервисы запущены в кластере (например, minio или keycloak):

kubectl get namespaces

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

kubectl get pods -A -o yaml

В списке ingress-ов можно увидеть имена виртуальных хостов и правила маршрутизации трафика (на уровне L7):

kubectl get ingress -A

Пример вывода:

NAMESPACE  NAME  CLASS  HOSTS      ADDRESS    PORTS
minio    minio  nginx  s3.domain.local  10.10.10.10  80,  443

Configmap-ы предназначены для хранения настроек в виде пар "ключ-значение". И хотя не рекомендуется хранить в них учётные данные, ключи и подобные настройки, они там все равно встречаются. А ещё скрипты, настройки coredns и другие конфигурационные файлы. Поэтому заглянем и туда:

kubectl get configmaps -A -o yaml

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

kubectl get secrets -A
kubectl get secret -n <namespace> <secret_name>

Если в списке ingress-ов мы обнаружили виртуальный хост, а при обращении к нему получаем 404, то для поиска нужного пути можно посмотреть логи nginx (для каждого пода ingress-nginx-controller).

kubectl get logs -n ingress-nginx ingress-nginx-controller-<id>

Анализируя полученную информацию, мы можем получить доступ к сервисам. Например, мы в конфиге пода обнаружили, что используются значения из секрета minio для доступа к S3-хранилищу на узле minio.minio.svc.cluster.local. А в списке ingress-ов увидели, что виртуальный хост s3.domain.local доступен на хосте 10.10.10.10, и входящий трафик на порт 443/TCP перенаправляется на под minio в неймспейсе minio. Используя значения секрета, мы получили доступ к содержимому бакетов в S3-хранилище и реализовали один из бизнес-рисков.

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

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

Вот например, в прошлом году эксперты из нашей команды MDR разоблачили довольно непростую вредоносную кампанию Horabot, нацеленную на жителей Мексики (более 5 тыс. жертв).

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

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

И не только потому, что в коде найдены комментарии на бразильском португальском. Часть этих комментариев написана очень формальным языком, что выдаёт использование LLM (то есть это могло быть "ложным флагом"). Но есть и комментарии на сленге, который понятен только носителям живого бразильского диалекта португальского языка. Например, слово "sapecar".

Что означает это слово, а также другие подробности расследования и индикаторы компрометации для выявления атаки Horabot — смотрите в статье Матеуса Сальгадо и Доменико Кальдареллы.

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

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

В частности, так делает APT-группа Librarian Ghouls (Rare Wolf, Rezet). Они рассылают жертвам фишинговые письма с архивами, имитирующими различные документы на русском языке (платёжные поручения, накладные). При открытии архива запускается установщик, который доставляет на компьютер жертвы дополнительные вредоносные модули. И среди прочего, в скомпрометированную систему устанавливается Mipko Employee Monitor, что позволяет атакующим шпионить за жертвой.

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

Для обнаружения Mipko Employee Monitor обратите внимание на создание, запуск и загрузку следующих файлов:

MPK.exe
MPK64.dll
MPK.dll
MpkL64.exe
MpkHCA.dll
MPKView.exe
Lsynchost.exe

Кроме того, программа регистрирует в системе службу с именем "MainLSyncHost" (Local Synchronization Host)" и исполняемым файлом Lsynchost.exe. Эту активность можно обнаружить:

— в журналах ОС Windows: события создания служб в журнале System (event id 7045) и Security (event id 4697),

— в реестре: за счет создания специфичных ветвей и ключей, связанных с сервисом, в директории HKLM\SYSTEM\CurrentControlSet\Services\MainLSyncHost.

Также из-за наличия функционала перехвата ввода с клавиатуры, данное ПО может детектироваться AV- и EDR-решениями с вердиктами keylogger — в случае отсутствия настроенных исключений (напомним, что Mipko Employee Monitor используется во многих организациях как легитимный продукт, а значит, антивирусы могут игнорировать эту программу).

Недавно наши пентестеры разбирались с утилитой PEAS для работы с Exchange ActiveSync (EAS) — и наткнулись на интересную проблему. При попытке получить листинг файловых шар через Document Library Access утилита падала с ошибкой 141 (LegacyDeviceOnStrictPolicy). При этом проверка учётных данных через --check работала нормально.

Оказалось, что раньше PEAS работал без ошибки, потому что серверы не требовали обязательного прохождения процедуры Provisioning. А когда администраторы начали включать строгие политики безопасности на Exchange, серверы стали требовать прохождения этой процедуры.

Provisioning в EAS — это механизм согласования политик безопасности между устройством и сервером через стандартный двухшаговый обмен, где клиент принимает политики безопасности сервера, а сервер в ответ разрешает дальнейшие операции. По итогу сервер выдает PolicyKey — токен доверия для конкретного аккаунта/устройства/сервера. Этот токен меняется при первом подключении нового устройства или когда админы обновляют политики; токен также может меняться от бездействия (длительного отсутствия входа в почту).

То есть без валидного PolicyKey сервер просто отклоняет запросы к данным. Интересный момент: сервер не может реально проверить, применило ли устройство политики — он полностью доверяет клиенту. Достаточно просто пройти протокольный обмен и сказать "да, я всё применил".

Раньше, когда серверы не требовали прохождения Provisioning, утилита PEAS просто отправляла PolicyKey=0. Но теперь это может не работать, поскольку сервер теперь может потребовать валидный токен.

Для решения этой проблемы наши эксперты пропатчили PEAS, добавив автоматический Provisioning перед UNC-операциями. Теперь утилита сначала выполняет двухфазный обмен с сервером, получает валидный PolicyKey и только потом делает запросы к файловым шарам. Дополнительно добавили флаг --policy-key для переиспользования ключа при массовых операциях, это убирает лишние запросы и уменьшает шум в логах.

Если хочется поглубже понять механизм EAS и исторический контекст утилит, можно посмотреть подробную статью от создателей PEAS, опубликованную ещё в 2016-м. Похоже, что тема всплывает раз в пять лет, и мы как раз подвезли актуализацию.

Что делать защитникам:

Необходимо следить за Microsoft Exchange как за критичным узлом, который зачастую становится "открытой дверью" к почте, файлам и внутренним ресурсам. Поэтому:

— По возможности вырубайте легаси-функциональность (EAS Document Library/UNC и прочие пережитки), сокращайте исключения и совместимость со всем подряд.

— Если отключить нельзя, используйте поведенческий контроль клиентов EAS: проверяйте, что перед доступом к данным всегда есть нормальный двухфазный Provisioning, следите за всплесками Status=141/142 и HTTP 449, смотрите динамику PolicyKey (внезапные смены/реюз между устройствами — знак тревоги).

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

— Ограничивайте срок жизни кэшированных PolicyKey и фиксируйте их привязку к аккаунту/серверу/устройству. Тащите всё это в SIEM с привязкой "аккаунт >> устройство >> PolicyKey >> операции". Потому что в Exchange может быть всякое: смешанные политики, странные клиенты, исторические хвосты конфигураций — и это регулярно выстреливает.

Главная мысль: EAS по дизайну доверяет заявлению клиента о принятии политик. Это нормально для протокола, но с точки зрения защиты нельзя опираться только на EAS. Добавляйте поведенческий мониторинг, внешнюю проверку комплаенса (MDM/Intune) и минимизируйте поверхность атаки за счёт отключения ненужного наследия.

Вы когда-нибудь задумывались о персональном ИИ-помощнике, который делает всё, что вы пожелаете? Как в фильме Her. Сейчас такая фантазия как будто почти реальна: LLM-агент OpenClaw быстро набирает популярность.

Но как мы предсказывали ещё в прошлом году, LLM-агенты становятся популярным вектором атак. И к уже известным проблемам безопасности OpenClaw недавно добавилась ещё одна, о которой расскажем сегодня.

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

LLM-агенты принимают решения на основе языковой модели, а действуют с помощью кода, вызовов API или утилит ОС. При слабых ограничениях на действия и доступ к данным агент может повести себя слишком самостоятельно. Такова природа больших языковых моделей: они выдают статистически уместные ответы на основе текущего контекста. Здесь ключевое слово - статистически.

Можно возразить, что существуют тщательно прописанные prompt’ы. Но LLM обучены быть полезными, и если не получается достичь результата описанным способом, они могут искать альтернативные пути решения задачи.

Иногда эти альтернативы разумные. А иногда - выходящие далеко за рамки того, что предполагал пользователь. В частности, действия агента могут приводить к компрометации узла, на котором работает LLM-агент.

Так получилось и в нашем случае: мы проанализировали агента OpenClaw и нашли способ добиться RCE. При посещении специально подготовленной веб-страницы агент OpenClaw выполняет команды оболочки в контексте пользователя, под которым запущен процесс.

В ответ на наш репорт вендор сообщил, что рассматривает описанное поведение как prompt injection, а не дефект агента, и потому не квалифицирует его как уязвимость.

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

1. Запускайте OpenClaw в Docker-контейнере, изолировав его от чувствительных данных и инфраструктуры.

2. Ограничивайте инструменты, например, установив подтверждение всех системных команд exec.ask=always.

3. По возможности отключите использование exec.

4. В средах с высокими требованиями к безопасности лучше вообще воздержаться от использования OpenClaw.

Общий вывод: с агентами на базе LLM мы делегируем не только «что сделать», но и «как именно». Без строгих ограничений это чревато неожиданными и опасными последствиями.

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

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

Сейчас наши эксперты наблюдают новую вредоносную кампанию группировки Head Mare (Rainbow Hyena), нацеленную на российские организации. Злоумышленники используют скомпрометированные сервера TrueConf, распространяя заражённые дистрибутивы клиентского приложения для видеоконференций TrueConf; при установке такого приложения на устройство жертвы ставится бэкдор.

Предполагается, что основным вектором атаки является уязвимость серверов TrueConf, выявленная в августе 2025 года и уже эксплуатировавшаяся в прошлом году.

Рекомендации по защите:

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

Кроме того, атаку можно обнаружить с помощью EDR, SIEM или MDR-сервисов на основе отслеживания следующих событий и процессов:

— Подмена файлов-клиентов приложения TrueConf на сервере TrueConf в директории C:\Program Files\TrueConf Server\ClientInstFiles\;

— Обращения к подозрительным доменам от процесса клиентского приложения C:\Program Files\TrueConf\Client\TrueConf.exe;

— Загрузка подозрительных библиотек процессом клиентского приложения C:\Program Files\TrueConf\Client\TrueConf.exe;

— Обращения процесса C:\Program Files\TrueConf\Client\TrueConf.exe к IP-адресам из необычных регионов;

— Создание подозрительных файлов и процессов клиентским приложением C:\Program Files\TrueConf\Client\TrueConf.exe;

— Создание подозрительных дочерних процессов от имени серверного процесса tc_webmgr.exe.

Продробности и дополнительные индикаторы компрометации — в статье "Кампания Head Mare с бэкдором PhantomPxPigeon и зараженными установочными файлами ПО TrueConf"

Решения компании 1С сейчас лидируют среди систем управления ресурсами предприятия (ERP) на российском рынке. Поэтому выросло и число атак через программное обеспечение 1С: как мы уже рассказывали, атакующие используют тривиальные ошибки в настройках, включая аккаунты с пустыми паролями.

А сегодня разберём другой кейс: в последнее время на пентестах и в реальных атаках встречается использование запуска командных оболочек от ERP. На скриншоте выше — пример проведения разведки с помощью таких команд.

Как обнаружить:

В серверной архитектуре 1С обычно работают несколько ключевых процессов:

ragent.exe — агент сервера 1С. Он отвечает за управление кластером, запуск рабочих процессов, распределение нагрузки.

rphost.exe — Remote Procedure Host. Это основной рабочий процесс платформы. В нём исполняется серверная логика: код конфигурации, запросы к СУБД, бизнес-процессы.

rmngr.exe — Cluster Manager. Это компонент управления кластером, отвечающий за балансировку, распределение сеансов и контроль рабочих процессов.

Нормальным поведением перечисленных ключевых процессов считается работа с СУБД, обработка клиентских запросов — но не запуск командных оболочек (cmd, powershell и др.), которые используются для атак.

Детектирующее правило:

logsource:
category: process_creation
product: windows
detection:
parent_process:
ParentImage|endswith:
- '\sqlservr.exe'
- '\rphost.exe'
- '\rmngr.exe'
- '\ras.exe'
interpreter_image:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
interpreter_originalfilename:
OriginalFileName:
- 'Cmd.Exe'
- 'PowerShell.EXE'
- 'pwsh.dll'
- 'WScript.exe'
- 'CScript.exe'
condition: parent_process and (interpreter_image or interpreter_originalfilename)

В зависимости от размеров инфраструктуры, правило можно разбить. Например, для cmd, powershell и разделить серверные приложения.

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

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

— сервисы резервного копирования могут быть использованы для компрометации вашей системы, особенно если это сервисы на основе протокола NDMP;

— работа с бэкапами кустов реестра позволяет обойти проверки безопасности и извлекать секреты из реестра Windows без привилегий SYSTEM;

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

Раньше мы каждый год выпускали два отдельных отчёта об инцидентах: от команды Managed Detection and Response (MDR) и от команды Inсident Response (IR). Для примера можно посмотреть такую статистику за 2023 год и за 2024 год.

А в этом году сделали один общий отчёт — и сейчас расскажем, почему.

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

Однако для более детального изучения угрозы желательно её наблюдение на всех этапах. А в условиях MDR это невозможно, поскольку вредоносная активность обнаруживается и предотвращается на ранних стадиях атаки, не успев развиться до ущерба.

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

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

Поэтому можно с уверенностью утверждать, что статистики инцидентов MDR и IR покрывают оба возможных профиля:

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

Короче, объединение статистик MDR и IR позволяет лучше понимать нынешние и грядущие угрозы. Как это получилось в деталях — смотрите в глобальном отчёте.