eBPF: E for Evil

Наверняка вы так или иначе сталкивались с технологией eBPF в своей повседневной работе, но задумывались ли вы о том, как ее могут использовать злоумышленники в своих атаках? Мы задумались и:
👽разобрали процесс загрузки eBPF-модулей в ядро и структуру загружаемых программ
👽 придумали подход к обнаружению вредоносных eBPF-программ
👽 реализовали PoC для предотвращения загрузки модулей в ядро
👽 написали парсер для структур-инструкций и строк eBPF-программы
Ниже вас ждут некоторые технические подробности нашего ресерча, с полной версией которого можно ознакомиться в нашем блоге.


eBPF: анатомия технологии и программы

За загрузку eBPF-программ в ядро отвечает системный вызов bpf() с командой BPF_PROG_LOAD (cmd = 5):

int bpf(int cmd, union bpf_attr *attr, unsigned int size);

Его мы и будем перехватывать с помощью kprobe. Второй аргумент содержит в себе структуру bpf_attr, в которой содержится множество полезной информации о загружаемой программе (представлены наиболее полезные элементы):

struct {
    __u32          prog_type;  /* тип eBPF-программы */
    __u32          insn_cnt;   /* число инструкций загружаемой программы */
    __aligned_u64  insns;      /* указатель на массив структур-инструкций */
    ...
    char           prog_name[BPF_OBJ_NAME_LEN]; /* имя загружаемой программы */
    ...
}

Самая интересная информация хранится по указателю insns. Внутри лежит массив структур, являющихся инструкциями eBPF-программы:

struct bpf_insn {
  __u8   code;    /* opcode */
  __u8   dst_reg:4;  /* dest register */
  __u8   src_reg:4;  /* source register */
  __s16  off;    /* signed offset */
  __s32  imm;    /* signed immediate constant */
};

Информация из этих структур использована для реализации Prevention и Detection (в kernel mode и user mode).


eBPF: Detection & Prevention (kernel mode)

Полученные структуры перебираются, из них выбираются инструкции BPF_EMIT_CALL() (code = 133):

#define BPF_EMIT_CALL(FUNC)
  ((struct bpf_insn) {
    .code  = BPF_JMP | BPF_CALL,
    .dst_reg = 0,
    .src_reg = 0,
    .off   = 0,
    .imm   = ((FUNC) - __bpf_call_base) })

Эти инструкции отвечают за вызов bpf-helpers. На основании используемых вредоносной программой хэлперов, а также имени загружаемой программы, можно сделать паттерны для детекта:

    if detectname == "pamspy":
        funclimitpatterns = {
        14: 1, #bpf_get_current_pid_tgid
        1: 1, #bpf_map_lookup_elem
        4: 5, #bpf_probe_read
        3: 1, #bpf_map_delete_elem
        16: 1, #bpf_get_current_comm
        132: 1, #bpf_ringbuf_submit
        131: 1, #bpf_ringbuf_reserve
        }
        prognamepatterns = ["handle_", "det_"]

Prevention выполняется при помощи замены первой инструкции анализируемой программы на инструкцию BPF_EXIT_INSN().


eBPF: Detection (user mode)

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

BPF_EMIT_CALL(get_current_pid_tgid)
BPF_STX_MEM(BPF_DW, BPF_REG_FP, BPF_REG_A, -8)
BPF_LDX_MEM(BPF_W, BPF_REG_ARG1, BPF_REG_X, 0)
BPF_JMP_IMM(BPF_JEQ, BPF_REG_ARG1, 0, 18)
BPF_EMIT_CALL(get_current_task)
BPF_MOV64_IMM(BPF_REG_ARG1, 2480)

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

[{'insn_number': 29, 'string': 'sudo\x00'}, 
{'insn_number': 44, 'string': '/etc/sudoers\x00'}]

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


eBPF: Проблемы и выводы

Главное, что нам удалось выяснить - анализ eBPF-программ возможен до их загрузки, можно даже предотвратить загрузку программы, если она вызывает подозрения. Конечно, не обошлось без сложностей из-за ограничений eBPF, но так или иначе мы смогли их обойти.
Почитать код, в котором мы реализовали описанные подходы, можно на Github.

Linux-сафари с Falco: как поймать атакующих за хвост

Количество атак на Linux-системы растет, а сами они прогрессируют:

🫡 целей для атак становится больше в связи с переходом на Linux;

🫡инструменты атакующих становятся более сложными и требуют новых подходов для обнаружения.

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

Поэтому мы используем не auditd, а Falco — open-source инструмент, который изначально предназначался для контейнерных сред, но отлично подходит и для стандартных Linux-систем без контейнеризации.

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

Конфигурация для Falco от команды Solar 4RAYS

Недавно мы рассказывали о преимуществах Falco — open-source инструмента, который изначально предназначался для контейнерных сред, но отлично подходит и для мониторинга стандартных Linux-систем без контейнеризации.

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

👽 отслеживать запуски процессов и сетевые соединения;

👽 детектировать создание файлов через memfd, загрузку EBPF-модулей и другие техники;

👽 фиксировать действия самоудаляющихся процессов.

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

Подробнее о подходах, примерах правил и реальных сценариях использования вы можете узнать из нашей статьи и выступления на SOC Forum.

Скачивайте нашу конфигурацию для Falco на GitHub.

Особенности новой версии Gorgon Stress

Недавно мы рассказывали об утилите Gorgon Stress, предназначенной для осуществления DDoS-атак. С тех пор авторы успели выпустилить новую версию — 1.9.9.8.2.

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

В этой версии злоумышленники:

✅изменили работу HTTP Flood,
✅добавили новый тип атаки,
✅использовали PROXY Protocol в HTTP Flood, что может ввести в заблуждение средства защиты от DDoS-атак.

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

Давайте уже после Чек-лист: что нужно успеть до праздников

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

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

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

👽проведите инвентаризацию,
👽сделайте бэкапы,
👽установите патчи,
👽наведите порядок с паролями и учетными записями,
👽сделайте оценку компрометации. 

Подробности читайте в блоге.

Кстати, на недавнем SOC Forum мы выстапили с докладом на тему ошибок, которые команды допускают в процессе реагирования. Коллеги из «Лаборатории Касперского» выпустили замечательный пост на ту же тему — не забудьте изучить. Но лучше, конечно, не доводить до инцидента и воспользоваться советами из нашей памятки.

С наступающим!🌲

Событие 1015 журнала Windows-SMB Server/Security

В одном расследовании, которое мы сейчас проводим, наша команда столкнулась с применением одной из APT-группировок известного всем Impacket.

На исследуемых системах аудит присутствовал в виде стандартных журналов ОС в состоянии «по умолчанию». При анализе мы зафиксировали цепочку событий, характерную для удаленного выполнения команд через модуль AtExec:

😬 4624 LogonType 3 журнала «Security», содержащее полезные данные в виде IP-адреса системы источника и используемой учётной записи;

😬 события 106, 100, 110, 129, 102, 200, 201, 141 журнала «Microsoft-Windows-TaskScheduler/Operational» — создание, запуск, завершение и удаление задачи планировщика. При этом имя создаваемой задачи по умолчанию соответствует регулярному выражению [a-zA-Z]{8};

😬 4634 журнала «Security» и LogonId совпадающим с LogonId события 4624.

Мы обратили внимание на событие с Event id 1015 журнала «Microsoft-Windows-SMBServer/Security» в окрестностях выполнения команд на хосте через AtExec. Оно приведено на скриншоте 👆

На сервере была включена подпись SMB-пакетов. Этот механизм повышает защищённость взаимодействия по данном протоколу и эффективен против NTLM-Relay атак.

Помимо того, что это событие подсвечивает аномалии, связанные с работой сервера SMB, оно содержит полезную информацию в виде IP-адреса системы-источника — адрес клиента.

А еще журнал, в котором оно содержится, как правило, ротируется значительно медленнее привычного журнала Security.

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

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

Чем полезен журнал Event Trace Logs

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

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

1️⃣ Самой ранней обнаруженной вредоносной активностью являлось выполнение PowerShell-команды от имени системы для запуска Reverse Shell к серверу атакующего, которую мы обнаружили в журнале PowerShell.

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

2️⃣ Здесь нам и пригодились журналы ETL. Windows записывает предупреждения, ошибки и другие события на уровне приложений и системы в двоичный файл — журнал трассировки событий, или же ETL.

В ETL-журнале C\Windows\System32\WDI\LogFiles\ShutdownPerfDiagLogger.etl мы обнаружили запись о процессе, который выполнил команду ReverseShell, а с помощью полей PID и PPID смогли восстановить нужную цепочку процессов:

* postgres.exe
** cmd.exe /c ""powershell.exe -ep bypass -EncodedCommand <base64>""
*** powershell.exe  -ep bypass -EncodedCommand <base64>

Таким образом мы подтвердили гипотезу, что виновником инцидента был необновленный PostgreSQL.

Для обработки данного артефакта вы можете воспользоваться проектом ETLParser, который доступен на GitHub.

Продолжаем отслеживать NGC5350

Сегодня хотим поделиться любопытной информацией о кластере NGC5350, который коллеги по индустрии именуют группировкой Hellhounds.

Недавно на публичный мультисканер из России загрузили ELF-семпл DecoyDog под именем «33»:

03b007a5fbb9d1556b4bedd6e930463ce35f5ae17b245edc58c12eb086de891f

Захардкоженный в теле семпла хэш коммита GitHub: revision 673a05b1.

Это connect-имплант DecoyDog, а не DNS, про который чаще выпускали статьи коллеги по индустрии. Он подключается к указанному C2, используя заданный тип транспорта. Конфиг рассматриваемого семпла:

"launcher": "connect",
"launcher_args": ["-t", "ec4", "--host", "185.143.221.125:80"]

Также в конфиге были SSL-сертификаты с датой начала действия (Not Before): 16/07/2024 15:34:40.

Информация по C2 — 185.143.221.125 Moscow AS 51659 (LLC Baxet). В 2024 резолвился в:


ns1.dpi-srv-s01.net
ns2.dpi-srv-s01.net

Домен зарегистрирован 2024-08-28. По информации из сертификатов, образец мог использоваться уже в июле 2024.

На 185.143.221.125 на порту 49364/TCP мы обнаружили сертификат с характерным Subject:


Subject C=ZZ, O=Pupy, CN=185.143.221.125

Это сертификат proxy-сервера DecoyDog. Подобные сертификаты используются в golang-коде утилиты proxy из GitHub Pupy и упоминались в первой статье Infoblox.

Сертификат создан на следующий день после начала действия сертификатов семпла.

По параметрам сертификата Proxy можно найти дополнительные Proxy-серверы DecoyDog или Pupy:

5.252.176.63 MIVOCLOUD (39798) Moscow, Russia
91.210.107.141 ORG-LVA15-AS (50867) Moscow, Russia
5.252.176.45 MIVOCLOUD (39798) Moscow, Russia
52.184.34.71 MICROSOFT-CORP-MSN-AS-BLOCK (8075) Hong Kong

Разберем детальнее каждый IOC

1️⃣ 5.252.176.63:64539 (01.06.2024-01.06.2025)

Тут Issuer не пустой: Issuer C=ZZ, O=Pupy CA.

В 2024-01-11 стал резолвиться в mp0.ignorelist.com, который использовался First Stage Decoy Dog Loader for Windows «MaxPatrol SIEM Agent.exe» из статьи «Hellhounds: Операция Lahat. Часть 2».

2️⃣ 91.210.107.141:62731 (31.08.2024-31.08.2025)

С 2024-08-01 резолвится в:

ns1.mow-srv-0074h.network
ns2.mow-srv-0074h.network

По неймингу похож на старые C2 DecoyDog.

Здесь поле Issuer пустое. Вышеупомянутая golang-утилита proxy генерирует сертификаты с непустым Issuer.

3️⃣ 5.252.176.45:29311 (25.09.2024-25.09.2025)

Здесь поле Issuer тоже пустое. IP упомянут в одном из GitHub, как «TOR Known Tor Relay/Route».

4️⃣ 52.184.34.71:9000 (01.10.2024-01.10.2025)

На 80/TCP CaddyServer— веб-сервак на Go.

Тут Issuer не пустой: Issuer C=ZZ, O=Pupy CA. В Names и CN вместо ожидаемого 52.184.34.71: 10.1.0.4

Что ещё интересного

Есть ещё старый DecoyDog из 2023 года с таким же revision 673a05b1 — _bareos.cfg:

d189e0150f42d2a2e40fefcec6973fcbc4a8b1a1757a358d13df3519ef275412

Загружен на мультисканер 2023-09-12 04:47:24 +0300 MSK от того же пользователя, что и упомянутый в начале поста семпл. Это тоже connect DecoyDog апреля 2023 года. Конфиг:

"launcher": "connect",
"launcher_args": ["-t", "ec4", "--host", "194.87.68.65:80"]

Этот семпл и C2 уже упоминались в первой части статьи «Hellhounds: операция Lahat».

Интересно, что в атаках в апреле 2023 и в летом 2024 года использовался один и тот же connect-имплант, но с разными C2.

IOC:

C2 connect DecoyDog:
185.143.221.125
194.87.68.65

proxy PupyRAT или DecoyDog:

5.252.176.45
5.252.176.63
52.184.34.71
91.210.107.141

Возможно, пустой Issuer — это показатель, что используется кастомная версия proxy, и перед нами не стандартный Pupy, а DecoyDog.

NGC4020: угроза, способная отключить оборону

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

Читайте статью «Как NGC4020 отключают вашу защиту, используя уязвимость в DameWare Mini Remote Control», чтобы узнать:

👽 Как через уязвимость в популярном инструменте удаленного администрирования злоумышленники проникли в инфраструктуру.

👽 С помощью чего им удалось обойти антивирус и какое ВПО использовалось для закрепления на атакуемых системах.

👽 Почему атакующим не удалось развить атаку.

Еще раз о десериализации 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 ключей мы разобрали здесь.

🚨 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.*, для которой пока что нет патча.

Критическая уязвимость 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. Если появятся какие-то подробности, мы расскажем о них в канале.

Пара слов о 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, быстро обнаружить злоумышленников не получится — а значит может быть уже слишком поздно.

Группировка 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. Дело в том, что в семплах мы нашли отсылки на исторические события и литературные произведения — атакующие демонстрируют свою эрудированность.

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

Критическая уязвимость в 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}},{{javanoscript}} и т.д.

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