🧩 BDU:2025-15156: когда IOC показывает эксплуатацию, но не называет payload
🛰 R&D-подразделение CRATU продолжает разбор IOC-набора из CRATU ThreatLens.
Следующий сюжет — блок с эксплуатацией BDU:2025-15156.
Он интересен своей неполнотой. В файле есть уязвимость, URL, IP и SHA256. Но инструмент или семейство malware не указаны.
Это важный кейс для SOC: не каждый IOC приходит с названием RAT, loader или ransomware. Иногда Threat Intelligence говорит только одно: была эксплуатация, был внешний узел, были файлы. Дальше цепочку нужно восстанавливать по телеметрии.
📟 Что видно в IOC
TTP: эксплуатация уязвимости BDU:2025-15156
URL: hxxp[:]//104[.]238[.]149[.]198[:]12349/BVN0VEdddye5odDFVR
IP: 104[.]238[.]149[.]198 23[.]235[.]188[.]3
Также указаны 2 SHA256.
Домены отсутствуют. Инструмент не указан. Поэтому здесь нельзя писать “это такой-то RAT” или “это такой-то loader”. Правильнее говорить: exploit-chain без названного payload.
🔎 Почему это важно
Для detection engineering такие блоки полезны: они учат не зависеть от имени вредоноса.
Если есть факт эксплуатации, необычный порт 12349, прямой URL на IP и файловые индикаторы, SOC должен проверять не только IOC-hit, но и всё, что произошло после него.
Уязвимость могла быть только входной дверью. Дальше могли появиться командная оболочка, загрузка файла, новый процесс от сервисной учётной записи, persistence или обращение к другому внешнему адресу.
Главный вопрос: что появилось на системе после эксплуатации?
🎯 MITRE ATT&CK: практический ориентир
В файле указан факт эксплуатации, но не указан конкретный инструмент. Для hunting-логики смотрим:
T1190 — Exploit Public-Facing Application T1105 — Ingress Tool Transfer T1059 — Command and Scripting Interpreter T1071.001 — Web Protocols T1505.003 — Web Shell T1543.003 — Windows Service
🛡 Как это детектить в SIEM / EDR
🔸 Обращение к IP и порту
Проверяем сетевые события к: 104[.]238[.]149[.]198:12349
🔸 URL с одноразовым токеном
Путь /BVN0VEdddye5odDFVR выглядит как случайный идентификатор. Его стоит проверять как возможный delivery или post-exploitation endpoint.
🔸 События после эксплуатации
Ищем новые файлы, запуск интерпретаторов, web-shell признаки, процессы от web/service accounts.
🔸 Дочерние процессы
cmd.exe powershell.exe sh bash curl wget certutil.exe
🔸 Persistence
Новые службы, scheduled tasks, Run/RunOnce, изменения конфигурации сервиса, неизвестные DLL/EXE рядом с приложением.
📌 Условие корреляции
Если система обращается к URL/IP из блока BDU:2025-15156, а затем появляются новые файлы, командная оболочка, процессы от сервисной учётной записи, web-shell признаки или persistence — поднимать инцидент как post-exploitation chain без malware-атрибуции.
🧠 Главный вывод
Не каждый IOC обязан называть вредонос. Иногда достаточно увидеть эксплуатацию и правильно задать вопрос:
какой процесс появился после exploit → что скачал → какие команды выполнил → закрепился ли в системе → куда пошёл дальше.