Netlify as malware delivery service 🙂

На днях, в ходе очередных Threat Intelligence исследований собрал паттерны активных серваков по доставке ВПО, в целом все как обычно - Powershell скрипты, VBS/BAT файлы и EXE 🤷‍♂️

Из интересного, в скриптах больше всего встречался домен netlify.app для стейджа малвари, это легитимный сервис в первую очередь предназначенный для деплоя веб приложений. Однако, как и любые легитимные сервисы он тоже активно эксплуатируется в атаках ❗️

Ниже описал варианты детектирования в логах DNS, запросы в Shodan для проактивного поиска серверов/IoC и сами сханченные индикаторы компрометации 🔥

🔍 Shodan

http.title:"Index of /" http.html:".ps1"
http.title:"Index of /" http.html:".bat"
http.title:"Index of /" http.html:".py"
http.title:"Index of /" http.html:".exe"

🛡 Detection

dns.question.name: *.netlify.app and source.ip: *

🛡 Indicators of Compromise (IoC's)

115.187.41[.]77
118.31.165[.]46
134.122.48[.]158

cyber-cryptor.netlify[.]app
extraordinary-malasada-f7721f.netlify[.]app
github[.]com/Khanzadaofficial/newss/tree/main

c0272f76195c0c20273644b5cf8948aa9a7ce1ee
a625351957b052b1af617bc8196855bc922d9252
e5dc572b9cdba19c7b6865a74ffa41bbb9744fdc

Happy hunting, hunters!

🧢 s0ld13r

➡️CVE-2025-9074: Escape from Tarkov Docker Desktop

Разбираем свежий крит в Docker Desktop для Windows и macOS, которая позволяет контейнерам полностью похекать хостовую систему.

➡️Суть проблемы

CVE-2025-9074 (CVSS 9.3) - это container escape уязвимость в Docker Desktop, исправленная в версии 4.44.3. Проблема в том, что любой контейнер может подключиться к Docker Engine API по адресу 192.168.65.7:2375 без какой-либо аутентификации.

➡️Механизм атаки

Исследователь Felix Boulet показал, что эксплуатация тривиальна:
Шаг 1: POST-запрос к /containers/create с JSON payload, который монтирует диск C:\ хоста в папку контейнера /mnt/host/c:/host_root
Шаг 2: POST-запрос к /containers/{id}/start для запуска контейнера с полным доступом к файловой системе хоста
Результат: Полная компрометация хоста с правами администратора

➡️Различия по платформам

Windows: Контейнер получает полный доступ к файловой системе, может читать любые файлы, перезаписывать системные DLL и эскалировать привилегии до администратора.
macOS: Docker Desktop имеет дополнительный слой изоляции, монтирование пользовательских директорий требует разрешения. Но злоумышленник все равно получает полный контроль над Docker и может бэкдорить конфигурацию приложения.
Linux: Буква ю - .... Использует named pipe вместо TCP-сокета для API. Линь снова оказалась самой безопасной ОСью))

➡️Альтернативные векторы атаки

Помимо вредоносного контейнера, уязвимость можно эксплуатировать через SSRF:
- Если приложение позволяет проксировать HTTP-запросы
- Особенно опасно, если SSRF поддерживает POST/PATCH/DELETE методы
- Можно достучаться до Docker socket через уязвимое приложение

➡️Техническая суть

По словам исследователя Philippe Dugre (zer0x64), это была "простая недоработка" - внутренний HTTP API Docker был доступен из любого контейнера без аутентификации или контроля доступа.
Enhanced Container Isolation (ECI) не защищает от этой уязвимости, что делает её особенно опасной.

➡️Меры защиты

Немедленно: Обновиться до Docker Desktop 4.44.3+
Проверка версии: docker --version
Мониторинг: Отслеживать подозрительные HTTP-запросы к 192.168.65.7:2375
Аудит: Проверить контейнеры на наличие подозрительных примонтированных дисков

🔗Источники:
- HackerNews
- NIST

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK