🐾 Когда 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

🚀 Команда SOC в Ecom.tech переходит на новый уровень и открывает две вакансии.

Ищем коллег, которые понимают, что работа в SOC — это не только про «горелые *censored*» в полночь, но и про азарт расследования и красоту работающих систем.

🕵️‍♂️ Кто нам нужен:

SOC-аналитик (L2)
Для того, кто не просто видит логи, а читает между ними целые истории. Кто по обрывкам данных восстанавливает полную картину атаки и находит то, что скрыто. Чья миссия — не просто закрыть инцидент, а докопаться до корня.
Что будет входить в зону ответственности:
*️⃣Расследование инцидентов (от первых признаков до отчёта)
*️⃣Проактивный поиск угроз (Threat Hunting)
*️⃣Анализ и триаж логов от систем защиты

Подробности на HH

🔧 SOC-инженер
Для того, кто смотрит на рутину аналитиков и думает: «А можно же сделать красивее и быстрее». Кто строит, интегрирует и автоматизирует, чтобы вся инфраструктура SOC работала как швейцарские часы.
Что будет входить в зону ответственности:
*️⃣Развитие и автоматизация SOC-инфраструктуры (SIEM, SOAR и др.)
*️⃣Настройка и улучшение детекторов и правил корреляции
*️⃣Интеграция новых источников данных и инструментов

Подробности на HH

Если в одном из этих описаний ты узнал не просто список обязанностей, а свою будущую работу — тебе к нам. Обсудим детали?

Отправляй своё резюме нашему рекрутеру Наталье в Telegram: @Natali_Ecom или откликайся по ссылкам на hh.

#вакансия #soc #soc_вакансия