GSocket: незаметный туннель в корпоративном лесу 🔍🌐

GSocket — сетевой “невидимка”, ставший одним из самых неприятных инструментов для blue team за последние годы.
Когда видишь его в инфраструктуре, это почти всегда признак: атакующий не просто заглянул — он собирается остаться подольше.
Что же это за зверь и почему о нём говорят во всех DFIR-отчётах?

🧑‍💻 Кто придумал?
Автор — Markus Kaiser (“Van Hauser”), лидер немецкой команды THC (The Hacker’s Choice), известной такими инструментами, как THC-Hydra.

🗓 Когда появился?
Проекту уже 10 лет: первые релизы — 2014–2015 год, массово замечен в атаках — с 2016 года.
GitHub проекта

💼 Как работает?
GSocket — кроссплатформенный инструмент для организации защищённого туннеля между жертвой и оператором через брокер, работающий где угодно: облако, TOR, VPS.
Жертва сама инициирует outbound-соединение, а трафик полностью шифруется и мимикрирует под HTTPS.

😳Бинарник — один, запуск без инсталляции, никаких открытых портов.
😳Интеграция с TOR, поддержка всех ОС.
😳Возможность запускать shell или проксировать любые порты.
😳Почти не оставляет следов после удаления.

🛡 Почему это опасно для компаний?

❗️Трафик выглядит как обычный HTTPS, а firewall (особенно если outbound открыт) не замечает ничего необычного.
⁉️Процесс gsocket может называться как угодно, прожить 10 минут и исчезнуть — если не поймать в момент работы, расследовать потом почти нечего.

🌍 Громкие атаки с использованием gsocket и его аналогов:
2017, Финансовый сектор Скандинавии:
Атакующие получили доступ к бухгалтерским серверам через фишинговую рассылку. Трафик на эксфильтрацию документов ушёл через gsocket на порт 443 — детектировали только по аномалиям в поведении сетевых сессий.
👉 FireEye — Banking Attacks Case Study

2021, крупная телеком-компания в Европе:
После компрометации внутренней облачной VM, злоумышленники подняли обратный shell через gsocket и смогли организовать дальнейшее lateral movement — incident-response команда нашла туннель только по ручной разборке JA3-фингерпринтов.
👉 Mandiant — JA3 Fingerprint Analysis

2022, логистический холдинг:
Использовался форк gsocket для скрытого RDP через прокси на TOR — расследование выявило туннель спустя неделю по анализу outbound-трафика.
👉 DFIR Report — RDP Tunneling with GSocket

Abusing tunneling tools in modern attacks:
Обзор современных техник, когда туннелирование строится через легальные сервисы, а не только через gsocket:
👉 WithSecure — Sliver C2 + Slack
👉 TrendMicro — Discord C2 abuse

🔗 Почему этим пользуются злоумышленники и pentester’ы:

✔️Удобно. Не надо возиться с настройкой портов.
✔️Шифрование “из коробки”.
✔️Легко маскируется под любой сетевой сервис.
✔️Быстро и просто удалить следы после завершения операции.

🤔 Мораль для SOC:
Если в инфраструктуре что-то внезапно вышло наружу через “обычный” HTTPS-трафик — это не обязательно Teams или Zoom. Мониторьте процессы, изучайте outbound-сессии, держите список подозрительных брокеров.

Если интересны техники детекта и конкретные рекомендации для blue team — см. следующий пост!

Я вообще хочу поподробнее раскрыть эту тему, это интересно и полезно, так что писанины тут будет много, готовьтесь, буду закидывать это порционно, чтобы 🧠 не лопнул)

#NASOC #GSocket #SOC #ThreatHunting #BlueTeam #CyberSecurity #Tunneling #DFIR

GSocket: как его ловить и почему он вызывает боль у SOC 🛡
GSocket —

это не просто “туннельщик” среди прочих. Это инструмент, который выбрали и pentester’ы, и реальные злоумышленники. Почему? Потому что он прост, универсален и скрытен настолько, насколько позволяет современная инфраструктура.

Почему gsocket становится вызовом для SOC и blue team?

🏃‍♂️ Все соединения идут наружу.
Даже если инфраструктура замкнута, внутренний сервер сам выходит наружу к брокеру — никакие “открытые порты” не нужны.

🕵️‍♂️ Шифрование и маскировка под HTTPS.
Бинарник не требует установки, запускается с любыми параметрами, трафик сливается с легитимным TLS-потоком.

🧳 Лёгкая интеграция с TOR и VPS.
Многие атаки используют внешние прокси, чтобы запутать расследование.

🔎 Может быть переименован или маскирован под безобидный процесс.
На хосте выглядит как любой “калькулятор”, “update.exe” и т.д.

💡 В отличие от chisel или ngrok, gsocket маскирует не только сам канал, но и способ запуска — это усложняет расследование. Стандартные tunneling-инструменты чаще выдают себя конфигами или специфическими путями, а gsocket легко “растворяется” в общем шуме инфраструктуры.

🔄 Реальные сценарии применения:
1️⃣Быстрый вывод данных после фишинга:
Сервер в бухгалтерии — эксфильтрация архивов через туннель, трафик — как обычный web.
2️⃣Pentest в облаке:
Получение shell на изолированной VM через разовый запуск gsocket, после чего туннель уничтожается.
3️⃣Обход сегментации:
Поднятие прокси между DMZ и внутренним сегментом, анализировать потом такой туннель можно только через поведенческие аномалии.

⚡️ Почему большинство стандартных SIEM-правил его не видит?
❌Нет сигнатур — нет срабатываний. Процесс может называться как угодно, путь до бинарника — любой.
❌Трафик на 443 порт — легитимный для почти любой инфраструктуры.
❌Процесс живёт мало, удаляется без следов.

🛡 Что реально может помочь?

*️⃣Анализ командных строк процессов:
--broker, --secret, --exec — если встречается, это “красный флаг”.

*️⃣Контроль outbound TLS-сессий:
Длинные, нетипичные по объёму/длительности сессии, особенно на неизвестные домены/IP.

*️⃣Сбор и анализ JA3-фингерпринтов:
Если TLS handshake не похож ни на что, что используют браузеры и приложения в компании, стоит копать глубже.

*️⃣Слежение за новыми бинарниками в temp-папках и подозрительных местах.

📝 Практика для SOC:

Включите регулярные отчёты о длительных outbound-сессиях на 443 порт.
Реализуйте правила на обнаружение процессов с подозрительными аргументами.
Обновляйте списки брокеров, доменов, хэшей бинарников по threat feeds.
Используйте YARA для поиска уникальных строк в бинарниках или памяти.

В следующем посте — примеры конкретных правил для hunt, работающие техники и небольшой SOC-чеклист.

#NASOC #GSocket #SOC #ThreatHunting #BlueTeam #CyberSecurity #Tunneling #DFIR

GSocket: практические методы обнаружения и hunt для SOC 🔎🛡
Давайте подытожим темку с GSocket, его трудно поймать “в лоб” — его задача как раз в том, чтобы затеряться в легитимном трафике. Но есть способы существенно повысить шансы на его обнаружение, если включить гибридный подход: мониторинг процессов, сетевого поведения и работу с индикаторами компрометации.

🖥 1. Контроль процессов и командных строк

✔️Мониторьте процессы, запущенные с ключами --broker, --secret, --exec, --listen — даже если сам бинарник называется иначе.
✔️Особое внимание — процессам из временных папок (C:\Users\<user>\AppData\Local\Temp, /tmp/, и т.д.).
✔️Логируйте команды запуска, чтобы собирать артефакты для дальнейшей triage.

Пример правила для Elastic SIEM:

{
"query": {
"bool": {
"should": [
{"wildcard": {"process.command_line": "*--broker*"}},
{"wildcard": {"process.command_line": "*--secret*"}},
{"wildcard": {"process.command_line": "*gsocket*"}},
{"wildcard": {"process.command_line": "*gs-netcat*"}}
]
}
}
}

🌐 2. Анализ outbound-трафика и TLS-сессий

✔️Настройте алерты на длительные исходящие TLS-сессии к редким или нехарактерным внешним адресам.
✔️Мониторьте крупные или нестандартные объёмы данных на порт 443, особенно к доменам и IP, которых нет в “белом списке”.
✔️Используйте сбор и сравнение JA3/JA3s-отпечатков — если fingerprint TLS не совпадает с обычными браузерами и корпоративными приложениями, это уже зацепка.

Пример правила для ELK:

{
"query": {
"bool": {
"must": [
{"match": {"network.transport": "tcp"}},
{"match": {"destination.port": 443}},
{"range": {"network.bytes": {"gte": 1000000}}}
],
"must_not": [
{"terms": {"destination.domain": ["корпоративные_домен1", "корпоративные_домен2"]}}
]
}
}
}

🧩 3. YARA и IOC

‼️Добавьте YARA-правила для поиска строк: gsocket, gs-netcat, Welcome to GSocket, --broker, --secret — как в файлах, так и в памяти процессов.
‼️Подписывайтесь на свежие threat feeds с IOC: брокеры, IP-адреса, хэши бинарников (регулярно обновляются на GitHub и в TI-платформах).
‼️Храните и обновляйте список известных JA3, подозрительных для вашей инфраструктуры.

🛠 4. Threat hunting: поведенческий анализ

🤘Сравнивайте паттерны сессий по времени, длительности, объёму и регулярности.
🤘Используйте корреляцию между аномальным запуском процесса и всплесками outbound-трафика.
🤘Внедрите визуализацию сетевой карты соединений — часто именно на ней выявляется “лишний” туннель.

п.с. это для крутышек с высоким уровнем зрелости, это и правда все сложно, но в целом умные люди которые собаку 🐶 на хантах съели советуют идти в эту сторону.

🚨 5. Реакция: что делать при срабатывании?
*️⃣Автоматически изолировать рабочую станцию или сервер.
*️⃣Снять дамп подозрительного процесса и бинарника.
*️⃣Заблокировать IP брокера/домен на периметре.
*️⃣Оповестить SOC для ручного triage и расследования.
*️⃣Проверить lateral movement: не было ли попыток двигаться дальше по сети через туннель.

GSocket всё ещё сложен для детекта, но грамотная аналитика плюс автоматизация — и ваша инфраструктура становится намного менее “комфортной” для таких инструментов.

Полезные ресурсы:
GSocket GitHub
Митре ATT&CK T1572
Public JA3 database
YARA-правила по tunneling tools

#NASOC #GSocket #SOC #ThreatHunting #BlueTeam #CyberSecurity #Tunneling #DFIR

🧠 eBPF: Мозговой чип для ядра Linux
📌 Что это
eBPF — технология, которая позволяет вживлять в ядро Linux микро-программы для анализа, мониторинга и даже модификации поведения ОС без пересборки и перезагрузки. Думай об этом как о плагинах для ядра, которые можно включать и выключать на лету.

💡 Зачем придумали

1️⃣Старые методы — модули ядра и патчи: долго, рискованно, легко положить систему.
2️⃣Нужно было собирать телеметрию и управлять ядром в продакшене, не ломая аптайм.
3️⃣eBPF = минимальная задержка, нет похода в userspace на каждый чих.

⚙️ Как это устроено

1. Пишем код (обычно на C или через bpftrace/bcc).
2. Компилим в байткод (clang -target bpf).
3. Грузим в ядро через bpf() или bpftool.
4. Верификатор проверяет, что код безопасен: нет бесконечных циклов, доступов к чужой памяти.
5. Привязываем к событию (hook): syscall, tracepoint, kprobe, LSM, XDP.
6. Срабатывание: ядро исполняет eBPF-код прямо внутри себя.

Пример:

bash
# Список загруженных eBPF-программ
bpftool prog show
# Список eBPF-карт (maps)
bpftool map show

🎯 Куда можно подцепиться

*️⃣kprobes/kretprobes — произвольные функции ядра.
*️⃣uprobes — функции в юзерспейсе (профилирование процессов).
*️⃣tracepoints — встроенные точки трассировки.
*️⃣XDP/TC — фильтрация трафика на входе.
*️⃣LSM hooks — контроль доступа и политики безопасности.

🔐 Риски для ИБ
❗️LPE через баги в eBPF (пример: CVE-2021-3490).
❗️Руткиты на eBPF: скрытие процессов, трафика, файлов.
❗️Обход мониторинга: подмена хуков, фильтрация логов.
❗️Шпионаж: перехват содержимого файловых операций, сетевых вызовов.
❗️DoS ядра: утечки памяти через eBPF map, тяжёлые фильтры.

📊 Для SOC

✔️Логировать системный вызов bpf():

bash
auditctl -a always,exit -F arch=b64 -S bpf

✔️Регулярно проверять загруженные программы (bpftool prog show).
✔️Ограничить загрузку eBPF → убрать CAP_BPF у сервисных аккаунтов.
✔️Следить за LSM/eBPF хуками и изменением политик безопасности.

⚠️ Запомни: eBPF — это как rootkit, но легальный. Он либо твой лучший друг, либо инструмент атакующего. SOC должен видеть каждую попытку его использования, ну или стремиться к этому.

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

#ebpf #soc #linux #nasoc

🐾 Когда SOC живёт на «сыром» Linux: мониторим без Tetragon и Falco

Представь: у тебя продакшен, и ты понимаешь — надо видеть, что творится в системе.
Но Tetragon/Falco нет, и поставить их прямо сейчас нельзя. Что делать?

🔍 Мониторинг “на коленке”
📌 Задача 1 — Ловить загрузку eBPF и модулей ядра

# Загрузка eBPF-программ
auditctl -a always,exit -F arch=b64 -S bpf
# Загрузка модулей ядра
auditctl -a always,exit -F arch=b64 -S init_module -S finit_module

📌 Задача 2 — Видеть подозрительный exec

# Исполнение из /tmp
auditctl -a always,exit -F dir=/tmp -F perm=x
# Исполнение из /dev/shm
auditctl -a always,exit -F dir=/dev/shm -F perm=x

📌 Задача 3 — Контроль смены UID/GID

auditctl -a always,exit -F arch=b64 -S setuid -S setgid

📌 Задача 4 — Сеть
sysmon for Linux: exec, connect, file create/delete в JSON-формате.
Если совсем голо — conntrack -E или tcpdump.

📊 Мини-кейс: exec в /tmp → алерт в SIEM
1. Настройка auditd :
auditctl -a always,exit -F dir=/tmp -F perm=x
2. Лог auditd: type=EXECVE msg=audit(1723450105.123:456): argc=1 a0="/tmp/m.sh"
3. SIEM-правило (KQL):
event.dataset:"linux.auditd" AND process.executable:/tmp/*
4. Профит
✅Ловим запуск скриптов/бинарей из временных директорий.
✅Коррелируем с outbound-соединением → возможный C2.

⚠️ Минусы ручного подхода
➖Шум: много событий, без enrichment.
➖Нет цепочек: события не связаны между собой.
➖Сложно масштабировать на десятки/сотни хостов.
➖Настройка и поддержка — ручная, без централизованного управления.

💡 Логичный следующий шаг
Если ты уже понял, что:
😳Ловить надо не только exec, но и цепочку событий (exec → setuid → connect).
😳Хочешь enrichment (родительский процесс, контейнер, namespace).
😳Нужно масштабирование и автоматизация.

Значит пришло время смотреть в сторону Tetragon и Falco — инструменты, которые закрывают эти боли.

🔜 В следующем посте — сравню их в лоб: что умеют, чем отличаются, и какой брать под SOC.

#linux #monitoring #soc #nasoc

🛠 Tetragon vs Falco: кто твой SOC-напарник в мире eBPF
В прошлом посте мы мониторили Linux «на коленке».
Да, оно работает. Но шум, отсутствие цепочек, нулевая масштабируемость… и ты понимаешь — так долго не протянешь.
Хочется:
👊Ловить не просто события, а контекст (кто запустил, из какого контейнера, в каком namespace).
👊Строить цепочки (exec → setuid → connect) и триггерить алерты только тогда, когда это реально атака.
👊Централизованно рулить политиками на сотнях хостов.
👊Делать всё это без боли.

💡 Тут на сцену выходят Tetragon и Falco.

🧩 Что это за звери
Falco — старожил Kubernetes-безопасности. Слушает syscalls через ptrace/eBPF, сравнивает с правилами, бьёт тревогу. Отлично интегрируется с контейнерными оркестраторами.
Tetragon — свежак от Cilium. Чисто eBPF, глубже в ядро, умеет LSM hooks, богатый фильтр событий, гибкость на уровне селекторов.

⚡️ Ключевые отличия для SOC
Смотри картинку.

📌 Пример: ловим exec в /tmp
Falco правило:
- rule: Exec from tmp
desc: Detect exec from /tmp
condition: proc.name in ("/tmp", "/var/tmp", "/dev/shm")
output: "Exec from tmp: %proc.cmdline"
priority: WARNING

Tetragon политика:
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
spec:
kprobes:
- call: "do_execveat_common"
args:
- index: 0
type: "string"
selectors:
- matchArgs:
- index: 0
operator: "Prefix"
values: ["/tmp/", "/dev/shm/"]

🕵️‍♂️ Falco vs Tetragon глазами атакующего
🤞Если на хосте Falco:
😎Можно попытаться работать «под шум» — запускать команды через процессы, которые уже разрешены в правилах.
😎При грамотной настройке всё равно словит нестандартные пути и ключевые syscalls, но при дефолтных правилах есть шансы проскочить с кастомными шеллами или нестандартными бинарями.
😎Falco ловит, когда ты делаешь что-то «не так», но можно замаскировать под «так».

🤞Если на хосте Tetragon:
😳Тут сложнее: eBPF с LSM-хуками даёт SOC возможность видеть даже твои попытки обойти мониторинг.
😳Tetragon может отследить события до того, как они реально изменят систему (pre-hooks), что затрудняет скрытность.
😳Чтобы обойти, атакующему нужно или эксплуатировать баг в eBPF/ядре, или снимать хуки — что само по себе палится.
💡 Вывод: Falco проще обойти при слабой настройке, Tetragon сложнее обмануть технически, но обе системы можно «похоронить» при полном root-доступе. SOC должен мониторить и сам факт вмешательства в датчики.
🏆 Итог для SOC
🤘Falco — быстро стартануть, особенно в Kubernetes.
🤘Tetragon — максимальная детализация и контроль.
В идеале: ставить оба (Falco для K8s, Tetragon для bare metal) и коррелировать события в SIEM.

🔜 В следующем посте — как включить базовые политики в Tetragon и превратить их в боевые алерты SOC.

#ebpf #tetragon #falco #soc #nasoc

Всем привет! Ноябрь обещает быть SOCчным 😎 Приходите на SOC форум, мы будем выступать с докладом:

1️⃣Про то как выбирать TI фиды?
2️⃣Какие проблемы с этим есть?
3️⃣Почему это важно для SOC ?

Так же разберем что такое контекст в фидах? Почему он важен? Посмотрим на типичные ошибки при выборе поставщика и дадим чек лист само проверки.

Наше выступление будет частью крутого трека «Тренды и аналитика угроз», где сплошная криминальная интрига! 🔍

Так что ждем всех 18 ноября в зале 3 на нашем докладе! Будет жарко, интересно и очень практично. 🔥

#soc #nasoc #socforum #SOCизнутри

Интриги, расследования и новые техники атак — это все в треке «Тренды и аналитика угроз». Встречаемся 18 ноября в зале 3 на таких докладах:

✳️ IDFKA Backdoor: скрытая угроза Rust-имплантов в современных APT-атаках. Владимир Степанов, аналитик, Солар. Время: 12:00.

✳️ Как «киберпартизаны» шпионят за российскими организациями. Георгий Кучерин, старший исследователь угроз информационной безопасности, Kaspersky. Время: 12:30.

✳️ 20 самых интересных техник из публичных исследований киберугроз. Олег Скулкин, руководитель Threat Intelligence, BI.ZONE. Время: 13:00.

✳️ Результаты расследований инцидентов ИБ за 2025 год. Денис Гойденко, руководитель департамента комплексного реагирования на инциденты ИБ, Positive Technologies. Время: 14:45.

✳️ ИИ, МСБ и APT — как меняется фишинг. Роман Стрельников, руководитель направления по информационной безопасности, 1С-Битрикс. Время: 15:15.

✳️ Практический выбор TI Feeds для российского SOC: что работает сегодня. Полина Саушина, старший аналитик SOC, и Сергей Бнятов, руководитель центра мониторинга и расследования киберинцидентов, ecom.tech (ex. Samokat.tech). Время: 15:45.

✳️ API как главный вектор атак на современные гибридные инфраструктуры. Денис Батранков, директор по развитию бизнеса, Гарда. Время: 16:15.

Успейте зарегистрироваться до 7 ноября.

#программа

🧩 Пост 4 — eBPF в деле: политики, логи и правила для SOC

У меня тут отпуск, а это значит самое время добить историю про eBPF. Ну как добить, точно буду писать еще, потому что целую книжку купил) Но об этом в другой раз)

В прошлых постах мы разобрались, зачем вообще мониторить ядро и почему Falco и Tetragon — не игрушки, а must-have для SOC.
Теперь — мясо. Разбираем, как из eBPF-событий сделать боевые алерты.

⚙️ 1. Включаем политику
Берём Tetragon — он умеет eBPF+LSM и детально видит процессы.
Пример политики: отслеживаем подозрительные execve из временных директорий (классика малвари ).

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: suspicious-exec
spec:
  kprobes:
    - call: "do_execveat_common"
      args:
        - index: 0
          type: "string"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Prefix"
              values: ["/tmp/", "/dev/shm/"]

💡Почему это важно: /tmp — любимое место для дропперов и скриптов, особенно если exec происходит от системных UID.

🧾 2. Что попадает в логи
Tetragon отдаёт JSON-структуру в stdout или Loki/ELK:

{
  "process_exec": {
    "parent": "bash",
    "binary": "/tmp/payload",
    "uid": 1000,
    "pod": "web-frontend-42",
    "namespace": "prod"
  }
}

Сразу видно — кто, откуда и где в кластере/хосте запустил бинарь.

🔎 3. Пишем правило в ELK
Kibana Query (Lucene):

process_exec.binary: "/tmp/*" AND NOT process_exec.parent: "systemd"

🔔 Что делает:
ловит все бинарники, запущенные из временных директорий, кроме системных процессов.
🧠 4. Корреляция и фильтры
Часто /tmp — и легитимные билды. Как делать меньше фолсов:
1️⃣ Исключить namespace: dev или user: ci-runner.
2️⃣ Обогатить событие через CMDB / asset-инвентори (hostname → роль).
3️⃣ Делать цепочки: exec → connect → write — алертить, только если есть поведение (например, исходящее соединение).

⚡️ 5. Профит для SOC
❕eBPF фильтрует шум в ядре → меньше фолсов.
❕Лог содержит контекст: кто, где, из какого контейнера.
❕Корреляции в SIEM становятся простыми и точными.
❕SOC начинает детектить поведение атак, а не отдельные exec.

💬 В следующем посте — реальный кейс расследования: как eBPF помог отследить эскалацию привилегий и восстановить цепочку атаки, когда на уровне логов было тихо.

#nasoc #tetragon #soc #ebpf #siem

🔥 Пост 5 — Расследование eBPF-руткита (пошагово для SOC)

Разберем потенциальную ситуацию с конями 🐴 в вакуме, коротко: web-приложение с RCE → payload в /tmp → загрузили eBPF-программу, которая вешала хуки на vfs_read и tcp_sendmsg, перехватывала данные и маскировала трафик. Tetragon — триггер, SIEM — корреляция, IR — containment → forensics → remediation.

1) Первичный сигнал (Tetragon)
Сработали сразу 2 алерта:

1️⃣exec-in-tmp — /tmp/.kworker запущен от nginx (PID 4123), container web-frontend-3
2️⃣ bpf-load — bpf(BPF_PROG_LOAD) от PID 4123

Пример лога Tetragon (JSON):

{
  "time":"2025-11-06T03:42:10Z",
  "event":"exec",
  "process": {"pid":4123,"ppid":2890,"exe":"/tmp/.kworker","args":["/tmp/.kworker"],"user":"www-data"},
  "container":{"id":"c9a3...","name":"web-frontend-3","pod":"web-frontend-3"},
  "policy":"exec-in-tmp"
}

{
  "time":"2025-11-06T03:42:12Z",
  "event":"bpf_load",
  "process":{"pid":4123,"exe":"/tmp/.kworker"},
  "bpf":{"type":"kprobe","target":"vfs_read,tcp_sendmsg","id":57}
}

2) Быстрая корреляция в SIEM (KQL пример)
Найти события, связанные по PID и тайм-винду ±2 мин:

(event.dataset:"tetragon.exec" AND process.pid:4123) 
OR (event.dataset:"tetragon.bpf" AND process.pid:4123)
OR (event.dataset:"tetragon.net" AND process.pid:4123)
| sort by @timestamp desc

Цепочка: exec (/tmp/.kworker) → bpf_load → connect(dst=185.41.23.22:443) → vfs_read hooks observed.

3) Немедленные действия (Containment — 0–15 минут)
1. Изоляция хоста/контейнера: kubectl cordon / docker pause / применить NetworkPolicy: block egress.
2. Блокировать egress на FW/NGW: по IP/портам, которые выявлены.
3. Не рестартить хост/контейнер (чтобы не потерять артефакты).
4. Снять список процессов и сетевых соединений:

ps auxf | grep 4123
ss -tunap | grep 4123
lsof -p 4123

5. Сохранить бинарник

cp /tmp/.kworker /srv/forensics/host123/.kworker.bin
sha256sum /srv/forensics/host123/.kworker.bin

4) Forensics: eBPF артефакты и анализ (15–90 минут)
a) bpftool — ревизия eBPF

# показать проги
bpftool prog show
# найти id по PID/attach type
bpftool prog show | grep 4123 -B4 -A4
# дамп xlated/btf
bpftool prog dump xlated id 57 > /srv/forensics/host123/bpf_prog_57.txt
bpftool map show > /srv/forensics/host123/bpf_maps.txt

b) анализ программы
❗️bpftool prog dump xlated — читабельный IR, ищем строки вроде kprobe__vfs_read, kprobe__tcp_sendmsg.
❗️strings /tmp/.kworker — ищем URL/домены/C2-хэши.
❗️readelf -h /tmp/.kworker / file /tmp/.kworker — тип файла, UPX-packed
c) поиск persistence
❕Проверить crontab, systemd units, init scripts.
❕Проверить /etc/ld.so.preload, ~/.bashrc, контейнер image layers.
d) память (если возможно)
➡️gcore <pid> или procdump / gdb для дампа процесса.
➡️Сохраняем /proc/<pid>/maps, /proc/<pid>/fd.

#nasoc #ebpf #tetragon #forensics #incidentresponse #linuxsecurity

5) Network forensic — C2 и exfil
Собрать поток с помощью tshark/tcpdump

tcpdump -n -s 0 -w /srv/forensics/host123/conn_185.41.23.22.pcap host 185.41.23.22 and port 443

Индикаторы:
😑dst_ip: 185.41.23.22 (пример)
😑порт: 443, TLS SNI — часто пустое/странное.

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

6) Глубокий анализ бинарника
strings → look for open, send, C2 strings.
hexdump → найти вставленные ELF внутри (self-extractors).
yara по известным сигнатурам (если есть).
Проверить, использует ли бинар map-ы eBPF (символы BPF_).

7) Корень проблемы (root cause)
❌ Уязвимый WP-плагин позволил сделать POST → RCE (веб-лог показал POST на /wp-content/plugins/evil.php).
❌RCE скачал payload в /tmp, сделал chmod +x и exec, затем зашёл в bpf() и загрузил eBPF-руткит, который:
🌚скрывал трафик (фильтровал логи/изменял вывод)
🌚перехватывал чтение файлов (vfs_read) для похищения секретов
🌚перехватывал tcp_sendmsg для инжекции/эксфильтрации

8) Remediation (hours → days)
1. Патчим/удаляем уязвимый компонент (WordPress plugin)
2. Реимеджим контейнер/восстановление из known-good image
3. Rotate credentials: все сервисные аккаунты/ключи/пароли, которые могли быть прочитаны
4. Удаляем eBPF проги и maps (только после снятия дампов):

bpftool prog detach id 57
bpftool prog pin id 57 /sys/fs/bpf/old_57
bpftool map show | awk '{print $1}' | xargs -n1 bpftool map unlink

5. Проверяем kernel modules: lsmod | grep suspicious и cat /proc/modules
6. Полный скан на IOC во всей инфраструктуре (SIEM: искать exec из /tmp, bpf loads, и соединения на C2)
7. Проводим root cause meeting, post-mortem и deploy security fixes

9) Playbook для SOC (чеклист)
🔜Триггер: exec из /tmp OR bpf_load detected → пометить приоритет High
🔜Корреляция по PID/timestamp/hostname → собрать цепочку
🔜Изолировать / блокировать egress
🔜Скопировать бинарник и дампы в forensics storage
🔜Запустить bpftool + ss + lsof + ps + tcpdump
🔜Сделать дамп процесса/памяти (если допустимо)
🔜Провести статический/динамический анализ бинарника
🔜Поиск persistence и lateral movement
🔜Ротировать секреты & патчим уязвимый апп
🔜SIEM: разослать правила по похожим событиям и hunt по всей сети

10) Уроки и превентивные меры
✅Мониторь факты загрузки eBPF всегда — auditctl -S bpf и Tetragon/Falco.
✅Лимитируй CAP_BPF/CAP_SYS_ADMIN для сервисов.
✅Whitelist eBPF owners — разрешай загрузку только от доверенных процессов.
✅Обогащай события (container id, pod, image hash, CMDB).
✅Автоматическая корреляция: exec → bpf_load → connect = авто-сигнал к расследованию.
✅Регулярный аудит bpftool/progs/maps на всех нодах.

Заключение

eBPF даёт атакующим новые векторы: rootkit-уровень перехвата и маскировки. Но тот же eBPF — и щит: если SOC умеет ловить загрузки, корелировать события и быстро реагировать, атака останавливается на ранней стадии. Этот кейс — классическая цепочка: RCE → /tmp exec → bpf_load → C2. Если ты поймал всё это — у тебя хорошие шансы всё поправить без масштабных потерь.

#nasoc #ebpf #tetragon #forensics #incidentresponse #linuxsecurity

🕵️ Operation Aurora: Китайская атака, которая вскрыла будущее кибервойн

Привет всем! Хочу попробовать новую тему с разбором и историческим контекстом, посмотрим как зайдет.👋

Сегодня — разбор одной из самых знаковых кибератак в истории. Operation Aurora — не просто взлом Google и Adobe в 2009 году. Это история о том, как государственный шпионаж вышел на новый уровень.

🤔 Что случилось? Кратко

Целевая атака на Google, Adobe, Juniper и еще ~20 компаний. Цель — не деньги, а исходные коды и доступ к почте китайских диссидентов и правозащитников.

Реакция Google была взрывной: «Хватит! Мы больше не будем мириться с цензурой в Китае». Компания практически ушла с рынка. Это был беспрецедентный шаг. 💣

🇨🇳 А почему Китай это сделал? Мотивы
Это не был вандализм. У атаки были четкие стратегические цели:
😳Технологический шпионаж 🚀: Кража исходных кодов поискового движка Google и ПО Adobe позволила бы резко ускорить развитие собственных технологий (китайских поисковиков Baidu, продуктов Adobe и т.д.). Классическая тактика «догнать и перегнать».
😳Политический контроль и слежка 🕶: Доступ к почтовым ящикам активистов позволял выявлять диссидентские сети, отслеживать контакты и подавлять инакомыслие. Это ключевая часть китайской киберстратегии.
😳Экономическое доминирование: Ослабление глобальных конкурентов и усиление национальных чемпионов.

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

👥 Подразделение 61398: «Шанхайские хакеры»

За атакой стояло Подразделение 61398 НОАК (Народно-освободительной армии Китая). Это не мифические «хакеры в балаклавах», а государственное учреждение.

📍 Расположение: Шанхай, массивное 12-этажное здание.

👨💼 Штат: Сотни, если не тысячи, высокооплачиваемых сотрудников, многие из которых выпускники лучших технических вузов.

🎯 Специализация: Промышленный шпионаж и кража интеллектуальной собственности.

В чем их фишка? Они мастера APT (Advanced Persistent Threat) — атак, которые длятся месяцами, требуют высочайшей квалификации и нацелены на конкретные долгосрочные цели.

🔎 Где еще они отметились?

Operation Aurora — лишь один эпизод в их карьере. Group 61398 (также известная как APT1) замешана в десятках громких атак:

⚡️ Взломы энергетического сектора США — попытки получить доступ к системам управления критической инфраструктурой.

🛡 Атаки на оборонных подрядчиков (Lockheed Martin и др.) — кража данных по новейшим военным разработкам.

📊 Кампания «Ночной Дракон» — массовая кража интеллектуальной собственности из нефтегазового сектора.

🦠 Атаки на фармкомпании во время пандемии COVID-19 — крача данных о вакцинах и методах лечения.

В 2014 году ФБР США даже выдвинуло официальные обвинения и объявило в розыск пяти офицеров из этого подразделения — это был исторический прецедент. 🚨

⚙️ Как работала атака? Техническая магия

1️⃣ Фишинг с допросом 🎣: Идеально персонализированные письма сотрудникам Google. Знали их имена, проекты, внутренний жаргон.
2️⃣ Zero-day в IE 🔓: Использовали уязвимость CVE-2010-0249 (Use-After-Free в обработчике таблиц). Открыл страницу — и твой компьютер уже под контролем хакеров.
3️⃣ Троян Hydraq 🚪: Стелс-бекдор, который:
1. Крал Kerberos-тикеты для движения по корпоративной сети.
2. Маскировался под легитимные системные процессы.
3. Позволял удаленно выполнять любой код.
4️⃣ Цель — система управления исходным кодом (MOMA): Хакеры получили доступ к «святому святых» Google — репозиторию, где хранился код поиска, Gmail и других ключевых сервисов.

💥 Последствия: мир после Aurora

😲Закат «доверенной» сети: Стало ясно, что враг уже внутри. Фаерволы и антивирусы бессильны против целевых APT-атак.

😲Бум инвестиций в безопасность: IT-гиганты начали срочно перестраивать архитектуру.

😲Начало киберхолодной войны: Кибератаки стали легитимным инструментом геополитики.

#nasoc #кибербезопасность #ZeroTrust #Аврора #Китай #APT1 #Group61398