HackSudo Thor: Полное прохождение тестирования на проникновение

Цель: HackSudo Thor с VulnHub
Задача: Получить root-доступ и прочитать /root/proof.txt
Среда: Изолированная лаборатория VirtualBox, сегментированная межсетевым экраном pfSense

Оглавление

• Обзор
• Сетевая топология
• Краткое описание цепочки атак
• Этап 1: Пассивная разведка
• Этап 2: Обнаружение сети и pfSense
• Этап 3: Сканирование и перебор целей
• Этап 4: Оценка уязвимостей
• Этап 5: Получение доступа
• Этап 6: Повышение привилегий
• Этап 7: Пост-эксплуатация
• Этап 8: Сокрытие следов
• Использованные уязвимости
• Используемые инструменты
• Рекомендации
• Структура репозитория
• Этическое предупреждение

Обзор

Этот репозиторий документирует частичное тестирование на проникновение методом «чёрного ящика», проведённое на HackSudo Thor — намеренно уязвимой виртуальной машине, опубликованной на VulnHub Вишалом Вагмаре. Целью было смоделировать реальную атаку, в которой внешний злоумышленник пытается скомпрометировать изолированную внутреннюю систему, с основной задачей получения root-доступа и чтения содержимого /root/proof.txt.

Оценка следует полному жизненному циклу тестирования на проникновение: пассивная разведка, обнаружение сети, перебор, оценка уязвимостей, эксплуатация, повышение привилегий, пост-эксплуатация и сокрытие следов.

Основными используемыми инструментами были Nmap для сканирования сети, Nessus для оценки уязвимостей и Metasploit Framework в качестве основной платформы эксплуатации и пост-эксплуатации. John the Ripper, Hashcat и онлайн-радужные таблицы использовались на этапе взлома паролей, хотя все попытки в конечном итоге оказались безуспешными из-за стойкости используемого алгоритма хеширования.

Сетевая топология

Виртуальная лаборатория была полностью построена в VirtualBox и спроектирована для имитации реалистичной корпоративной сети с тремя различными зонами безопасности, управляемыми межсетевым экраном pfSense 2.7.2. Три NAT-сети были настроены следующим образом: зона WAN, имитирующая общедоступный интернет, где находится машина атакующего Kali; зона DMZ, размещающая целевую машину; и внутренняя зона LAN, содержащая машины, не входящие в область оценки.``` Internet Zone — NatNetwork (10.0.2.0/24) │ │ Kali Linux 2025.4 [attacker] — 10.0.2.9 │ pfSense WAN interface — 10.0.2.8 │ ├── pfSense Firewall (boundary device) │ ├── DMZ Zone — DMZnat (10.0.4.0/24) │ ├── HackSudo Thor [TARGET] — 10.0.4.3 │ └── DVWA — 10.0.4.4 (out of scope) │ └── LAN Zone — LANnat (10.0.3.0/24) ├── Metasploitable 2 — 10.0.3.5 (out of scope) └── Windows XP Cyberlab — 10.0.3.4 (out of scope)

![Logical network topology diagram](https://assets.kitploit.com/production/public/readmes/36585/c827ed20ecf44ee4dad098bf9e027592664befa19581c4a9947368a33b245929.png)
*Логическая топология сети, зоны безопасности под управлением pfSense*

Интерфейсу WAN был назначен адрес `10.0.2.8/24` по DHCP, интерфейс LAN настроен на `10.0.3.1/24`, а интерфейс OPT1 (DMZ) — на `10.0.4.1/24`. Чтобы внести преднамеренную неверную конфигурацию в лабораторную среду, порт 80 был осознанно оставлен открытым на интерфейсе WAN pfSense, имитируя реальную ситуацию с доступом к панели управления, которая послужила основной точкой входа во внутреннюю сеть.

---

## Сводка цепочки атак```
[Kali Linux — 10.0.2.9]
        │
        │  CSRF-aware Python brute force → admin / pfsense
        ▼
[pfSense webConfigurator — 10.0.2.8:80]
        │
        │  Firewall rules disabled → DMZ and LAN now reachable
        ▼
[HackSudo Thor — 10.0.4.3]
        │
        │  Shellshock RCE (CVE-2014-6271)
        │  Apache mod_cgi → /cgi-bin/shell.sh
        ▼
[Meterpreter shell — www-data]
        │
        │  sudo -u thor /home/thor/hammer.sh
        │  Command injection via eval → bash -i payload
        ▼
[Interactive shell — thor]
        │
        │  GTFOBins: sudo service ../../bin/bash
        ▼
[Root shell]
        │
        ├── /root/proof.txt captured        ✅
        ├── /etc/shadow + /etc/passwd exfiltrated
        └── SSH RSA backdoor planted

Этап 1: Пассивная разведка

Перед любым контактом с целевой средой информация собиралась исключительно из общедоступных источников. Двумя основными источниками были официальная страница HackSudo Thor на VulnHub и публичный GitHub-профиль автора.

Страница на VulnHub подтвердила, что цель — система на базе Linux, рейтинг сложности «от лёгкой до средней», с задачей найти флаг proof.txt. Просмотр GitHub-профиля автора дал дополнительную информацию. Вишал Вагмаре последовательно создаёт Linux-машины типа «boot-to-root», где основная задача — повышение привилегий, и это относится ко всей серии HackSudo. Это сформировало модель угроз для активных этапов: HTTP и SSH — наиболее вероятная поверхность атаки, а путь повышения привилегий предполагался через неправильную конфигурацию sudo, злоупотребление SUID-бинарниками или эксплуатацию пользовательского сервиса.

Такой анализ паттернов автора важен и в реальных проектах. Понимание того, как, вероятно, спроектирована система и какие категории уязвимостей администратор, скорее всего, повторяет, даёт направление до отправки первого пакета.

Этап 2: Обнаружение сети и pfSense

Этот этап включал прямой активный контакт со средой. Целью было выявить все активные хосты, понять границы сети и составить полную картину поверхности атаки, прежде чем сузить фокус до основной цели.

Поиск граничного устройства

Сначала был выполнен лёгкий ping-скан Nmap (-sn) по WAN-подсети (10.0.2.0/24) для обнаружения активных хостов с минимальным шумом. Было обнаружено три хоста: 10.0.2.1 и 10.0.2.2 оказались стандартными адресами инфраструктуры VirtualBox, что оставляло 10.0.2.8 единственным хостом, не относящимся к инфраструктуре. Эта машина стала объектом немедленного внимания.

Полный SYN-скрытный скан 10.0.2.8 не дал никаких результатов. Это было ожидаемым поведением, а не ошибкой. Корпоративные межсетевые экраны спроектированы так, чтобы не отвечать на сканирование портов, молча отбрасывая пакеты вместо ответа. Отсутствие результатов само по себе подтверждало, что это граничное устройство сети, активно фильтрующее трафик.

Чтобы подтвердить, какие службы на самом деле работают, не полагаясь на сканирование пакетов, был выполнен прямой HTTP-запрос с помощью curl. Этот подход был выбран, потому что обычный веб-запрос с гораздо меньшей вероятностью будет отфильтрован, чем инструмент сканирования. Ответ пришёл как HTTP/1.1 200 OK с Server: nginx и заголовком страницы pfSense, что подтвердило прямой доступ к webConfigurator через порт 80 с WAN-интерфейса.

Обход CSRF для подбора пароля pfSense

После подтверждения страницы входа следующим шагом была попытка восстановления учётных данных. В качестве инструмента подбора был выбран Hydra, но эта попытка провалилась по двум причинам. Первая — практическая: rockyou.txt содержит более 14 миллионов записей, что делает его неприменимым в рамках данного тестирования. Вторая — техническая и более значимая: pfSense 2.7.2 реализует защиту CSRF-токенами, генерируя уникальный криптографический токен при каждой загрузке страницы, который должен быть отправлен вместе с учётными данными. Модуль HTTP POST в Hydra отправляет статическое тело запроса и не имеет механизма для динамического получения нового токена для каждой попытки, поэтому каждый запрос отклонялся ещё до проверки пароля.

Для обхода этого был написан пользовательский скрипт на Python, имитирующий полный процесс входа в браузере. Для каждой попытки пароля скрипт открывает новую сессию, загружает страницу входа, извлекает текущий CSRF-токен из HTML-формы, а затем отправляет учётные данные вместе с этим токеном точно так же, как это сделал бы браузер. Пользовательский список паролей был создан с помощью CeWL для сканирования страницы входа pfSense и извлечения релевантных терминов, затем дополнен fasttrack.txt для учёта известных учётных данных по умолчанию.

Скрипт восстановил учётные данные: admin / pfsense, — неизменённые по умолчанию.

Пользовательский скрипт на Python, восстанавливающий учётные данные pfSense

Картографирование внутренней сети

После получения доступа к панели управления была просмотрена конфигурация интерфейсов pfSense для понимания полной внутренней топологии. Это выявило две подсети, которые были невидимы из WAN: LAN (10.0.3.0/24) и DMZ (10.0.4.0/24). Затем через веб-интерфейс были отключены правила межсетевого экрана WAN и добавлены два разрешающих правила, разрешающих трафик с IP-адреса атакующего в обе подсети.

Ping-сканирование Nmap обеих подсетей выявило шесть активных хостов. Четыре из них были исследованы далее, за исключением 10.0.4.1 и 10.0.3.1, которые принадлежали интерфейсам шлюза pfSense. Против всех четырёх одновременно был выполнен комбинированный скан для обнаружения служб с определением версий, использованием скриптов NSE по умолчанию и определением ОС. Сопоставление результатов с данными пассивной разведки идентифицировало каждую машину в топологии:

Цель была подтверждена как 10.0.4.3. Все дальнейшие действия были сосредоточены исключительно на этой машине.

Этап 3: Сканирование цели и перебор

После идентификации цели был выполнен более глубокий анализ её служб для картирования поверхности атаки и определения возможных путей эксплуатации. В качестве основной платформы для этого этапа использовался Metasploit Framework, в частности потому, что его бэкенд PostgreSQL сохраняет все результаты сканирования между сессиями: хосты, службы и уязвимости хранятся в базе данных и доступны для просмотра на последующих этапах без повторного сканирования.

Перед началом работы Metasploit был инициализирован командой msfdb init, соединение с базой данных проверено командой db_status, и вся последующая работа велась из msfconsole.

Команда db_nmap использовалась для выполнения полного сканирования 10.0.4.3: SYN-скрытный скан, определение версий служб, скрипты NSE по умолчанию, определение ОС и все 65 535 TCP-портов. Результаты автоматически сохранялись в базу данных и извлекались командами hosts и services. Были подтверждены три открытые службы: FTP на порту 21 (Pure-FTPd), SSH на порту 22 (OpenSSH 7.9p1) и HTTP на порту 80 (Apache 2.4.38).

Затем каждая служба была исследована далее с помощью целевых вспомогательных модулей Metasploit. Наибольшее внимание было уделено службе HTTP. Модули dir_scanner и http_crawler использовались для картирования всех доступных путей и конечных точек на веб-сервере. Самым значительным результатом стало обнаружение каталога /cgi-bin/ и скрипта с именем shell.sh. Кроме того, ручной просмотр исходного HTML-кода страницы news.php выявил скрытый комментарий автора, ссылающийся на каталог /cgi-bin/, — намеренная подсказка, указывающая на уязвимость, связанную с CGI. Служба FTP была проверена на анонимный доступ (отключён), а строка версии была записана для сверки с CVE. Баннер SSH был получен для той же цели.

Этап 4: Оценка уязвимостей

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

Был создан пользовательский профиль Nessus с явно включённым сканированием CGI и тестированием веб-приложений, с целью на порты 21, 22 и 80. Эти настройки не включены по умолчанию и были критически важны; без них конечная точка CGI не была бы протестирована. Сканирование длилось примерно 11 минут и вернуло 41 результат. Действенными результатами были:

Два результата Shellshock на /cgi-bin/shell.sh немедленно стали приоритетными. CVE-2014-6271 имеет оценку CVSS 9.8 и позволяет неаутентифицированное удалённое выполнение кода — результат с самым высоким воздействием в сканировании. CVE-2014-6278 представляет собой неполное исправление той же уязвимости, то есть даже частично исправленные системы остаются эксплуатируемыми. Уязвимость SSH Terrapin была оценена как неэксплуатируемая без позиции «человек посередине». Остальные результаты не имели значимой ценности для эксплуатации в данном тестировании.

Перед переходом к эксплуатации результат Shellshock был независимо проверен с помощью NSE-скрипта http-shellshock Nmap, нацеленного непосредственно на /cgi-bin/shell.sh. Независимая верификация перед эксплуатацией — важный шаг в методологии, так как она подтверждает, что уязвимость реальна, а не является ложным срабатыванием сканера, и позволяет не тратить время на попытку эксплуатации, которая не сработает. NSE-скрипт подтвердил, что конечная точка уязвима, и CVE-2014-6271 был выбран в качестве основного вектора атаки.

Этап 5: Получение доступа

После подтверждения Shellshock начался этап эксплуатации. Уязвимость существует потому, что Apache mod_cgi передаёт HTTP-заголовки запроса как переменные окружения в Bash при вызове CGI-скрипта. В неисправленной версии Bash специально созданное определение функции в переменной окружения вызывает немедленное выполнение любых команд, добавленных после определения. Внедряя эту полезную нагрузку в заголовок User-Agent запроса к /cgi-bin/shell.sh, можно было выполнять произвольные команды на сервере без какой-либо аутентификации.

Модуль Metasploit exploit/multi/http/apache_mod_cgi_bash_env_exec полностью автоматизирует этот процесс. Модуль был настроен: RHOSTS установлен в 10.0.4.3, TARGETURI — в /cgi-bin/shell.sh, полезная нагрузка — linux/x86/meterpreter/reverse_tcp, а слушатель указывал на машину Kali через порт 4444. Запуск модуля отправил вредоносный запрос, сервер выполнил полезную нагрузку, и Metasploit принял входящее соединение, установив сессию Meterpreter от имени www-data.

Эксплойт Shellshock выполнен, и реверсивная оболочка Meterpreter установлена от имени www-data

Этап 6: Повышение привилегий

Начиная с www-data, степень доступа к системе изначально была неизвестна. Немедленным приоритетом было понять текущую позицию: кто активный пользователь, какие ещё учётные записи существуют и какие пути доступны для получения более высоких привилегий.

Сессия Meterpreter была сброшена до обычной системной оболочки, и с помощью модуля pty Python был создан псевдотерминал для получения полноценного интерактивного терминала. Чтение /etc/passwd и просмотр /home/ подтвердили наличие пользователя с именем thor. Первоначальная команда ls -la /home/thor/ вернула отказ в доступе, поэтому файловая система была просканирована на предмет любых файлов, принадлежащих thor, независимо от разрешений каталога, с помощью find / -user thor 2>/dev/null. Это позволило обнаружить аномальный бинарный файл /usr/local/sbin/ls, файл с именем ls, который не был стандартным системным бинарником. Его содержимое показало, что это пользовательский скрипт, принадлежащий Thor, который был отмечен для дальнейшего исследования.

Стадия 1: www-data → thor

Стандартный шаг пост-эксплуатации — проверка прав sudo текущего пользователя — был выполнен командой sudo -l. Это показало, что www-data разрешено выполнять /home/thor/hammer.sh от имени пользователя thor без требования пароля — правило NOPASSWD без каких-либо легитимных операционных оснований.

sudo -l подтверждает, что www-data может запускать hammer.sh от имени thor без пароля

Прямой доступ к чтению hammer.sh был заблокирован разрешениями каталога, поэтому он был сначала выполнен командой sudo -u thor /home/thor/./hammer.sh для наблюдения за его поведением. Скрипт предложил два интерактивных запроса: «Секретный ключ» и «Секретное сообщение». Первый запрос отображал введённые данные обратно в виде приветствия. Второй обрабатывал ввод, а затем завершался. Различие между этими двумя поведениями было значительным: если бы оба запроса просто отображали ввод, ни один не был бы интересен. Тот факт, что второй запрос обрабатывал ввод перед ответом, предполагал, что он передаёт значение в команду оболочки — шаблон, соответствующий оператору eval, который является хорошо задокументированной поверхностью для внедрения команд.

При втором выполнении в первый запрос был передан пустой ввод. Во второй была предоставлена полезная нагрузка внедрения bash -i. Это породило интерактивную оболочку от имени thor.

Полезная нагрузка bash -i, внедрённая в hammer.sh

Стадия 2: thor → root

sudo -l снова была выполнена от имени thor. Это показало неограниченный доступ NOPASSWD к /usr/bin/cat и service от имени root. Правило для service было наиболее значительным. Техника GTFOBins sudo service позволяет передать строку с обходом пути в качестве аргумента имени службы. Передача ../../bin/bash заставляет бинарник service разрешить обход и вызвать /bin/bash с привилегиями root.```bash sudo service ../../bin/bash

Это дало полноценную root-оболочку.

![Root shell obtained via GTFOBins](https://assets.kitploit.com/production/public/readmes/36585/3a31128b6403327522052289d3c9d3f470612643e9dbd6c7cc2f76cea3467ca4.png)
*Root shell obtained GTFOBins sudo service path traversal confirmed*

## Фаза 7: Пост-эксплуатация

После подтверждения привилегий root фаза пост-эксплуатации была сосредоточена на трёх областях: понимание окружения системы, извлечение конфиденциальных данных и обеспечение постоянного доступа.

### Информация о системе и флаг

Сначала была выполнена базовая системная разведка для подтверждения идентификации цели и создания контекста для рекомендаций по устранению уязвимостей, включая версию ядра, версию ОС и сетевую конфигурацию. Система была идентифицирована как Debian GNU/Linux 10 (Buster) с ядром 4.19.0-17-686-pae на `10.0.4.3`.

В домашнем каталоге root были найдены файлы `proof.txt` и `root.txt`. Файл `proof.txt` был прочитан для получения основного флага, что и было заявленной целью данного тестирования.

![proof.txt contents confirming root compromise](https://assets.kitploit.com/production/public/readmes/36585/c79551c28b5f059b53df3948f8ba247c28ba8a9f65132abd70d218a4d25c3370.png)
*Содержимое proof.txt — основной флаг получен*

### Извлечение учётных данных и взлом паролей

Файлы `/etc/shadow` и `/etc/passwd` были скопированы в `/tmp` и загружены на машину атакующего через Meterpreter. Вместе эти два файла предоставляют учётные записи пользователей системы и хеши паролей, необходимые для офлайн-взлома.

Было предпринято несколько подходов к взлому. John the Ripper определил оба хеша как SHA-512crypt с фактором стоимости 5000 итераций. Первая попытка с использованием `rockyou.txt` была прервана после нескольких часов работы без результата. Вычислительная сложность SHA-512crypt делает полный словарный перебор очень медленным без использования GPU. Вторая попытка с пользовательским целевым словарём, составленным на основе разведывательных данных, завершилась быстро, но не дала совпадений.

Затем была опробована CrackStation как онлайн-сервис радужных таблиц, но для обеих записей был возвращён нераспознанный формат хеша. Это было ожидаемо: SHA-512crypt добавляет уникальную случайную соль к каждому хешу перед хешированием, поэтому один и тот же пароль даёт разные хеши для разных учётных записей. Радужные таблицы работают путём предварительного вычисления хешей для известных паролей, но для каждого возможного значения соли потребовалась бы отдельная таблица, что делает этот подход совершенно непрактичным для солёных хешей.

Для финальных попыток использовался Hashcat с тремя словарями последовательно: `fasttrack.txt` (исчерпан за 4 секунды), пользовательский целевой список (исчерпан без совпадений) и первые 100 000 записей из `rockyou.txt` (не удалось за 3 минуты). Все попытки взлома паролей были безуспешными. Использование солёного SHA-512crypt с большим количеством итераций является причиной — алгоритм намеренно разработан как вычислительно затратный, как раз для предотвращения такого рода офлайн-атак.

### Поиск SSH-ключей

Также был проведён поиск по файловой системе на наличие закрытых ключей RSA и PEM-сертификатов с помощью `find`. Любой найденный закрытый ключ мог предоставить доступ к другим системам, доверяющим соответствующему открытому ключу, что является ценной возможностью для перемещения по сети. Закрытых ключей, принадлежащих другим системам, найдено не было.

### Развёртывание бэкдора

Постоянный доступ был реализован путём внедрения открытого ключа RSA в файл `authorized_keys` учётной записи root. Аутентификация по ключу SSH была выбрана, потому что она не полагается на пароли и её трудно обнаружить, если только файл `authorized_keys` не подвергается специальному аудиту. На машине Kali была сгенерирована пара ключей RSA длиной 4096 бит, а открытый ключ был добавлен в `/root/.ssh/authorized_keys` на целевой системе с установленными правильными правами на каталог и файл. Подключение обратно к целевой системе с использованием закрытого ключа подтвердило работоспособность бэкдора.

![SSH backdoor connection confirming persistent root access](https://assets.kitploit.com/production/public/readmes/36585/2c82f61eee9b44158a831bc2fa79a967e4130aad20f8e0bb2395d07a0a82f127.png)
*Постоянный root-доступ подтверждён аутентификацией по закрытому ключу*

### Автоматизация

Также был разработан пользовательский скрипт на Python для Metasploit RPC (`thor_full_chain.py`), который автоматизирует всю цепочку пост-эксплуатации. Скрипт подключается к активному сеансу Metasploit RPC и обрабатывает полную последовательность: стабилизацию оболочки `www-data`, внедрение hammer.sh для повышения привилегий до thor, повышение привилегий через GTFOBins до root, захват флага, извлечение учётных данных и развёртывание бэкдора с протоколированием временных меток, сохраняемым в локальный файл. Это был дополнительный результат, демонстрирующий возможность автоматизации цепочки атак с использованием API Metasploit RPC. См. `scripts/thor_full_chain.py` для полной реализации.

## Фаза 8: Сокрытие следов

Заключительная фаза включала удаление следов вторжения как с целевой системы, так и с атакующей машины Kali. На целевой системе наиболее критическим файлом для очистки был журнал доступа Apache, так как он содержал необработанный HTTP-запрос Shellshock, который вызвал начальную эксплуатацию. Журнал аутентификации был очищен, поскольку в нём хранились все команды sudo, использованные во время фазы повышения привилегий. Syslog, бинарные записи входа (`wtmp`, `btmp`, `lastlog`) и история bash для `root` и `www-data` были перезаписаны и проверены на пустоту.

На Kali рабочая область Metasploit была удалена командой `workspace -d default`, загруженные файлы учётных данных удалены, пара ключей SSH удалена, а история bash очищена. Каждый шаг проверялся перед переходом к следующему.

Одно намеренное исключение было сделано для SSH-бэкдора: его файлы ключей были сохранены на целевой системе и на данном этапе не удалялись, поскольку они были необходимы для демонстрационных целей в презентации оценки.

## Использованные уязвимости

| Уязвимость | CVE | CVSS | Компонент | Метод |
|--------------|-----|------|-----------|--------|
| Shellshock RCE | CVE-2014-6271 | 9.8 | Apache mod\_cgi + неисправленный Bash | Metasploit с вредоносным заголовком User-Agent |
| Учётные данные по умолчанию | — | — | pfSense webConfigurator | `admin / pfsense` без изменений после установки |
| Неправильная конфигурация sudo (www-data) | — | — | `/etc/sudoers` | NOPASSWD для `hammer.sh` как thor |
| Внедрение команд в hammer.sh | — | — | Пользовательский bash-скрипт | Внедрение `eval` через полезную нагрузку `bash -i` |
| Неправильная конфигурация sudo (thor) | — | — | `/etc/sudoers` | NOPASSWD для неограниченного `service` как root |

---

## Использованные инструменты

| Инструмент | Назначение |
|------|---------|
| Nmap | Обнаружение хостов, сканирование портов, определение ОС, проверка Shellshock с помощью NSE |
| Metasploit Framework | Разведка с поддержкой базы данных, эксплуатация, Meterpreter, пост-эксплуатация |
| Nessus Essentials | Структурированная оценка уязвимостей со сканированием CGI и веб-приложений |
| Hydra | Первоначальная попытка перебора pfSense неудачна из-за защиты CSRF |
| CeWL | Создание пользовательского словаря путём обхода страницы входа pfSense |
| Python 3 + BeautifulSoup | Скрипт перебора pfSense с учётом CSRF |
| pymetasploit3 | Клиент API Metasploit RPC для автоматизации полной цепочки атак |
| John the Ripper | Офлайн-взлом хешей SHA-512crypt |
| Hashcat | Попытки взлома SHA-512crypt с использованием GPU |
| CrackStation | Онлайн-поиск по радужным таблицам |
| GTFOBins | Справочник по технике повышения привилегий через sudo service |
| curl | Проверка HTTP-сервиса через WAN-интерфейс pfSense |

---

## Рекомендации

**Немедленно обновить Bash.** Уязвимость Shellshock существует, потому что Bash никогда не обновлялся в этой системе Debian 10. Выполнение `apt-get update && apt-get upgrade bash` устраняет уязвимость. Помимо исправления, если CGI-скрипты не требуются для работы, каталог `/cgi-bin/` следует полностью отключить в конфигурации Apache, удалив поверхность атаки независимо от версии Bash.

**Проверить и усилить правила sudo.** Два правила sudo с NOPASSWD составили всю цепочку повышения привилегий. Ни одно из них не имеет законного обоснования. Файл `/etc/sudoers` следует пересмотреть и удалить обе записи. Принцип наименьших привилегий должен определять любую будущую конфигурацию sudo; учётные записи должны иметь только те права, которые им действительно необходимы, и ничего больше.

**Удалить eval из сценариев оболочки.** Скрипт `hammer.sh` передавал пользовательский ввод непосредственно в оператор `eval` без какой-либо проверки или санитизации. Именно это сделало возможным внедрение команд. Использование `eval` следует полностью избегать в скриптах оболочки, которые принимают пользовательский ввод, так как это почти всегда является поверхностью атаки. Ввод должен проверяться на соответствие строгому белому списку перед любой обработкой.

**Изменить учётные данные pfSense по умолчанию и ограничить доступ.** WebConfigurator был доступен через интерфейс WAN с неизменёнными учётными данными `admin / pfsense`. Учётные данные по умолчанию следует изменить сразу после установки. WebConfigurator никогда не должен быть доступен из WAN; доступ следует ограничить только LAN или выделенным интерфейсом управления.

**Внедрить централизованное ведение журнала.** В фазе 8 все локальные журналы были очищены в течение нескольких минут, не оставив никаких следов вторжения на целевой системе. Это продемонстрировало, что на цели отсутствует централизованное управление журналами. В производственной среде журналы должны пересылаться в реальном времени на удалённую SIEM-систему. Это гарантирует, что даже если атакующий очистит локальные журналы, доказательства уже будут сохранены вне системы и не могут быть изменены.

---

## Структура репозитория```
hacksudo-thor-pentest/
│
├── README.md
├── report.pdf                          ← Full penetration testing report
│
├── scripts/
│   ├── pfsense_brute.py                ← CSRF-aware pfSense brute force script
│   └── thor_full_chain.py              ← Metasploit RPC attack chain automation
│
└── screenshots/
    ├── network.PNG
    │
    ├── Discovery/
    │   └── pfsenselogin.png
    │
    └── exploit/
        ├── sheellockexploit.PNG
        ├── sudol.PNG
        ├── hammer.bash-i.PNG
        ├── privilage escaltiontoroot.PNG
        ├── proof.PNG
        └── backdoor.PNG

Этическое предупреждение

Данный тест на проникновение проводился исключительно в автономной, изолированной виртуальной лабораторной среде, созданной в Oracle VirtualBox. HackSudo Thor — это намеренно уязвимая CTF-машина, опубликованная на VulnHub с явной целью обучения и практики в области безопасности.