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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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/"]

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

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