Источник: https://powerseb.github.io/posts/Another-phishing-tool
Дата публикации оригинала: Март 21, 2023
Перевел: BLUA специально для xss.pro
В этой статье я хотел бы познакомить вас с созданным мной инструментом/шаблоном, который можно использовать для подделки учетных данных и даже для работы с MFA. Эта работа в значительной степени основана на первоначальной статье mrd0x.
TL;DR
Новый фишинговый инструмент на базе noVNC, масштабируемый, с обратным прокси и на базе докеров - NoPhish. Идеально подходит для атак типа «противник посередине» (AITM).
Основная концепция
Итак, все мы знаем и любим фишинг. По моему опыту, существует два вида фишинговых атак:
Оба сценария имеют свои проблемы и возможные решения - в этой статье мы сосредоточимся на фишинге учетных данных. Поэтому, когда дело доходит до такого рода атак, главным врагом (или лучшей защитой) становится многофакторная аутентификация. Даже когда злоумышленник получает доступ к действительным учетным данным, вход в систему без этого фактора невозможен. Поэтому данный вектор атаки сильно зависит от сайта, который нужно подделать, и индивидуальных настроек пользователя - что негативно сказывается на успешности такой атаки.
До тех пор, пока статья mrd0x не изменила взгляд на эту тему - основная идея заключается в том, чтобы с помощью
Это был лишь краткий обзор, поэтому для получения более подробной информации прочтите полную статью о mrd0x.
Поскольку это реальный сайт и пользователь осуществляет реальный вход на него, может быть проведена многофакторная аутентификация, а злоумышленник по-прежнему имеет 100 % контроль над сессией пользователя.
В конечном итоге это дает злоумышленнику множество возможностей для дальнейших атак - например, экспорт куки-файлов сессии и вход в систему с их помощью, получение данных с помощью кейлоггера на машине с noVNC, манипуляция сетевым трафиком для предотвращения выхода из системы и последующего захвата сессии... и т. д.
С установленной концепцией давайте посмотрим, что новичок вроде меня может добавить к этому. Основная идея проста для понимания, но если бы я хотел настроить такую фишинг-инфраструктуру, я столкнулся бы с множеством вопросов. Так началось мое приключение по созданию простого решения, которое работает из коробки (как отличный Evilginx). В результате я подготовил инструмент / шаблон, который должен помочь другим легко настроить масштабируемую фишинг-инфраструктуру на базе noVNC и которая может легко использоваться в реальных сценариях — так что давайте начнем.
Как сделать его масштабируемым?
Итак, базовая концепция установлена, возможно, вы уже видите небольшую проблему - сессия vnc означает, что пользователь управляет предоставленной машиной. Если вы отправите одну и ту же ссылку двум разным пользователям, они оба подключатся к одной и той же машине и, следовательно, будут видеть действия друг друга (или бороться за управление мышью). Такая ситуация (хотя и забавная) будет очень неловкой, и ее следует избегать. Поэтому требование к нашей настройке заключается в том, что каждый пользователь, которого мы хотим контролировать, должен иметь отдельную vnc-сессию.
Для этого мы можем запустить столько vnc-сессий на нашем фишинговом хосте, сколько захотим - но нам потребуется немного мощности под капотом (так что никаких ec2 small
). Следующим и дополнительным недостатком является то, что нам нужно открыть соответствующий vnc-порт для каждой сессии - это может быть немного накладно. В идеале нам нужен всего один url, который затем перенаправляет на отдельные vnc-сессии, что делает настройку сети очень простой - достаточно открыть порт 80/443.
Прежде чем мы рассмотрим эту проблему распространения, мы можем сосредоточиться на нашей первоначальной задаче: один пользователь - одна vnc-машина - и пусть она будет небольшой (а в идеале - дешевой). Давайте поговорим о докере.
В процессе размышлений я также наткнулся на эту статью от fhlipzero, которая также вдохновила (и помогла) создать эту конструкцию.
Docker
Итак, ситуация похожа на типичный случай использования docker - мы хотим запустить небольшой процесс (браузер на машине с novnc) и масштабировать его с увеличением количества пользователей.
Мой личный опыт с Docker был нулевым, поэтому после множества чтения, проб и ошибок, слез и размышлений о карьере пекаря я нашел работающую настройку noVNC с браузером и узнал, как использовать это для своих целей.
Базовым докер-образом является accetto/ubuntu-vnc-xfce-firefox-g3 - в нем мы настраиваем несколько вещей:
Настройки noVNC:
Настройки контейнера:
Таким образом, это гарантирует, что наш контейнер готов принять пользователя. Но это лишь один контейнер для одного пользователя — нам необходимо создать контейнер для каждого пользователя. Поэтому эти шаги и настройки лучше всего разместить в dockerfile, и в результате у нас получится воспроизводимый контейнер noVNC, который можно надежно развертывать и использовать для фишинга.
Но ладно, я понимаю, что это все старая информация — это делает noVNC масштабируемым, но была еще проблема с подключениями, портами и т. д.
Reverse Proxy
Хорошо, прежде чем поговорить о моих потрясающих новых открытиях с Apache, давайте сначала определим, что такое обратный прокси и почему он нам нужен. Пожалуйста, имейте в виду, что следующее описание отражает мое понимание, и я прочитал много разных интерпретаций, так что хочу убедиться, что мы все на одной волне.
Обратный прокси — это Instance, который принимает запросы от клиентов и перенаправляет их на Instance в backend. Ответы от backend затем передаются обратно на обратный прокси, а оттуда — клиенту. Это означает, что клиент никогда не знает, что он общается с Instance backend — вся коммуникация туннелируется через обратный прокси.
Из-за этой особенности обратный прокси является идеальным дополнением к нашему сетапу — мы можем развертывать столько VNC-инстансов, сколько захотим, а обратный прокси обрабатывает все запросы разных пользователей. Это сэкономит нам множество открытых портов и упростит обнаружение потенциально других инстансов noVNC. Итак, как мы можем его настроить?
Поскольку я новичок в технологиях веб-серверов, я решил попробовать свои силы с Apache. Здесь было довольно просто использовать VirtualHosts в файле 000-default.conf. Вот пример конфигурации, которую я создал:
Вы заметите, что вместо поддоменов я решил использовать подкаталоги в обратном прокси. Это гарантирует, что наш сетап требует только одного имени хоста и каждый подкаталог перенаправляет на один контейнер noVNC. Это было сделано для того, чтобы сэкономить на работе и DNS-записях.
Но нам нужно больше, чем просто перенаправление к правильному контейнеру, поскольку соединения noVNC зависят от веб-сокетов, и поэтому нам также нужно перенаправлять эти соединения. Это делается с помощью записи
В принципе, это все, что требуется для настройки обратного прокси, что замечательно, потому что это очень просто и легко для понимания (что было очень важно, так как мне нужно было это понять).
Итак, мы разобрали все — в Apache мы используем модули прокси для достижения необходимого перенаправления. Мы настраиваем 000-default.conf для перенаправления наших соединений на соответствующие контейнеры VNC, и на этом всё.
Кроме того, эта конфигурация может быть также легко применена к контейнеру Docker, что идеально подходит для перехода к инструменту / скрипту, который я написал в качестве учебного опыта.
NoPhish - инструмент / настройка.
Итак, сочетая все вышеперечисленное, я представляю вам NoPhish. По сути, это полноценная фишинг-настройка на базе Docker, которая использует noVNC.
У нас есть образ Docker для наших контейнеров noVNC, который будет запускаться для каждого пользователя, которого мы хотим фишить, и один контейнер обратного прокси, который будет обрабатывать все входящие запросы и распределять их между различными контейнерами.
Кроме того, система будет извлекать все собранные куки (и куки сессий) из запущенных контейнеров noVNC — это происходит каждые 60 секунд. Результатом этого являются файлы cookies.json (для удобного импорта в предпочитаемое вами расширение).
Итак, это общее представление о cbcntvt и механизмах — теперь краткий обзор того, как это использовать.
Установка
Чтобы настроить инструмент, необходимо выполнить следующие требования:
Когда эти требования выполнены, клонируйте репозиторий и выполните setup.sh:
Таким образом, за кулисами этого волшебного bash-скрипта будут созданы образы Docker (на основе предоставленных Dockerfile). Затем мы можем начинать.
Запусти это!
Когда установка завершена (или если вы хотите начать новое вовлечение), вы можете запустить всю инфраструктуру с помощью скрипта setup.sh.
Вот краткий обзор параметров:
Итак, всё понятно — тогда мы можем запустить это:
Это запустит 4 VNC контейнера Docker (по одному для каждого пользователя), которые будут нацелены на URL
Система также поддерживает SSL; вам нужно только предоставить сертификат и ключ, и тогда она будет работать с HTTPS на порту 443. Если они не предоставлены, система будет работать с HTTP на порту 80.
Когда настройка начнется, она покажет вам следующий вывод:
Отображаемые URL-адреса для фишинга содержат случайные строки (в этом примере f325a55604e4d31f5a469d591e2c) — это должно обеспечить некоторую случайность в URL (чтобы заманить пользователя), скрыть VNC-соединения от сканеров и рандомизировать пароль VNC.
Затем скрипт начнет свой цикл для сбора куки и сессий. Чтобы не углубляться в слишком много деталей (потому что именно эта часть всего мероприятия чуть не довела меня до безумия) — цикл включает в себя следующие шаги:
Хорошо, возможно, немного инсайта — здесь сыграла роль моя упрямство. Контейнер noVNC использует Firefox в качестве браузера. Firefox обрабатывает сессионные куки и обычные куки по-разному. Обычные куки сохраняются в файле cookies.sqlite — легко читаемом и понятном. Сессионные куки сохраняются в памяти (лучше защищены, но не так хороши для нашей цели). Первоначальная реакция заключалась бы в том, чтобы использовать Chromium (который обрабатывает куки и сессионные куки иначе, чем Firefox), но я хотел найти способ с Firefox. После долгих поисков в Google (и переосмысления жизненных выборов) я наткнулся на файл recovery.jsonlz4. Этот файл создается Firefox для сохранения текущего состояния браузера, чтобы обеспечить его восстановление в случае сбоя — и он также содержит сессионные куки.
Вот почему в системе есть два скрипта, которые занимаются различными частями информации о пользовательской сессии. Каждый скрипт создаст отдельный JSON-файл (
Что касается формата JSON-файлов, настройка предлагает возможность создать простой файл
И это всё — вот как вы можете запустить инструмент.
Останови это!
Хорошо, вы провели свой отличный фишинг-тест — получили права администратора домена и так далее. Но что делать, чтобы остановить и удалить инфраструктуру?
Во время выполнения, если вы нажмете
Заключение
Надеюсь, я смог дать вам некоторое представление о данной фишинг-системе и более глубокое понимание того, как использовать noVNC в рамках фишинговой кампании. Пожалуйста, дайте знать, если инструмент/настройка (NoPhish) как-то помогли вам, что можно было бы сделать лучше, а @моему-будущему-я, надеюсь, ты снова вспомнил, как работает твой собственный инструмент.
Дата публикации оригинала: Март 21, 2023
Перевел: BLUA специально для xss.pro
В этой статье я хотел бы познакомить вас с созданным мной инструментом/шаблоном, который можно использовать для подделки учетных данных и даже для работы с MFA. Эта работа в значительной степени основана на первоначальной статье mrd0x.
TL;DR
Новый фишинговый инструмент на базе noVNC, масштабируемый, с обратным прокси и на базе докеров - NoPhish. Идеально подходит для атак типа «противник посередине» (AITM).
Основная концепция
Итак, все мы знаем и любим фишинг. По моему опыту, существует два вида фишинговых атак:
- Фишинг для получения учетных данных - вы хотите заманить пользователя на сайт, где он должен войти в систему, и вы можете получить его учетные данные.
- Фишинг с полезной нагрузкой - пользователь должен (скачать и) выполнить полезную нагрузку - знаменитый
iPhone.exe, который прикрепляется к письму.
Оба сценария имеют свои проблемы и возможные решения - в этой статье мы сосредоточимся на фишинге учетных данных. Поэтому, когда дело доходит до такого рода атак, главным врагом (или лучшей защитой) становится многофакторная аутентификация. Даже когда злоумышленник получает доступ к действительным учетным данным, вход в систему без этого фактора невозможен. Поэтому данный вектор атаки сильно зависит от сайта, который нужно подделать, и индивидуальных настроек пользователя - что негативно сказывается на успешности такой атаки.
До тех пор, пока статья mrd0x не изменила взгляд на эту тему - основная идея заключается в том, чтобы с помощью
noVNC заманить пользователя на ссылку, которая соединяет с машиной, где рабочий стол представлен в браузере. Но вместо обычного рабочего стола злоумышленник представляет полноэкранный браузер с настоящим целевым сайтом. Большим преимуществом этой техники является то, что злоумышленник имеет полный контроль над машиной (с vnc-подключением) и, следовательно, имеет полный контроль над браузером и сессиями в нем. Когда пользователь заходит на реальный сайт - злоумышленник получает доступ ко всей соответствующей информации о сессии, которая необходима для того, чтобы выдать себя за пользователя. Дополнительным преимуществом, с точки зрения злоумышленника, является то, что отображается реальный веб-сайт. Это означает, что пользователь взаимодействует с реальным целевым веб-сайтом и, следовательно, пользовательский опыт жертвы почти такой же.Это был лишь краткий обзор, поэтому для получения более подробной информации прочтите полную статью о mrd0x.
Поскольку это реальный сайт и пользователь осуществляет реальный вход на него, может быть проведена многофакторная аутентификация, а злоумышленник по-прежнему имеет 100 % контроль над сессией пользователя.
В конечном итоге это дает злоумышленнику множество возможностей для дальнейших атак - например, экспорт куки-файлов сессии и вход в систему с их помощью, получение данных с помощью кейлоггера на машине с noVNC, манипуляция сетевым трафиком для предотвращения выхода из системы и последующего захвата сессии... и т. д.
С установленной концепцией давайте посмотрим, что новичок вроде меня может добавить к этому. Основная идея проста для понимания, но если бы я хотел настроить такую фишинг-инфраструктуру, я столкнулся бы с множеством вопросов. Так началось мое приключение по созданию простого решения, которое работает из коробки (как отличный Evilginx). В результате я подготовил инструмент / шаблон, который должен помочь другим легко настроить масштабируемую фишинг-инфраструктуру на базе noVNC и которая может легко использоваться в реальных сценариях — так что давайте начнем.
Как сделать его масштабируемым?
Итак, базовая концепция установлена, возможно, вы уже видите небольшую проблему - сессия vnc означает, что пользователь управляет предоставленной машиной. Если вы отправите одну и ту же ссылку двум разным пользователям, они оба подключатся к одной и той же машине и, следовательно, будут видеть действия друг друга (или бороться за управление мышью). Такая ситуация (хотя и забавная) будет очень неловкой, и ее следует избегать. Поэтому требование к нашей настройке заключается в том, что каждый пользователь, которого мы хотим контролировать, должен иметь отдельную vnc-сессию.
Для этого мы можем запустить столько vnc-сессий на нашем фишинговом хосте, сколько захотим - но нам потребуется немного мощности под капотом (так что никаких ec2 small
). Следующим и дополнительным недостатком является то, что нам нужно открыть соответствующий vnc-порт для каждой сессии - это может быть немного накладно. В идеале нам нужен всего один url, который затем перенаправляет на отдельные vnc-сессии, что делает настройку сети очень простой - достаточно открыть порт 80/443.Прежде чем мы рассмотрим эту проблему распространения, мы можем сосредоточиться на нашей первоначальной задаче: один пользователь - одна vnc-машина - и пусть она будет небольшой (а в идеале - дешевой). Давайте поговорим о докере.
В процессе размышлений я также наткнулся на эту статью от fhlipzero, которая также вдохновила (и помогла) создать эту конструкцию.
Docker
Итак, ситуация похожа на типичный случай использования docker - мы хотим запустить небольшой процесс (браузер на машине с novnc) и масштабировать его с увеличением количества пользователей.
Мой личный опыт с Docker был нулевым, поэтому после множества чтения, проб и ошибок, слез и размышлений о карьере пекаря я нашел работающую настройку noVNC с браузером и узнал, как использовать это для своих целей.
Базовым докер-образом является accetto/ubuntu-vnc-xfce-firefox-g3 - в нем мы настраиваем несколько вещей:
Настройки noVNC:
- В файле
vnc.htmlбыли внесены те же изменения, которые предложили fhlipzero и mrd0x, чтобы гарантировать, что никакие элементы управления не отображаются, и переход к VNC-соединению является пустым. - Переименование настроенного
vnc.htmlвconn.html(чтобы не вызывать подозрений) - В файле
ui.jsбыл изменен заголовок страницы, чтобы он не выглядел слишком навязчиво
Настройки контейнера:
- Настройте конфигурацию xfce4 так, чтобы отображался только пустой белый экран
Таким образом, это гарантирует, что наш контейнер готов принять пользователя. Но это лишь один контейнер для одного пользователя — нам необходимо создать контейнер для каждого пользователя. Поэтому эти шаги и настройки лучше всего разместить в dockerfile, и в результате у нас получится воспроизводимый контейнер noVNC, который можно надежно развертывать и использовать для фишинга.
Но ладно, я понимаю, что это все старая информация — это делает noVNC масштабируемым, но была еще проблема с подключениями, портами и т. д.
Reverse Proxy
Хорошо, прежде чем поговорить о моих потрясающих новых открытиях с Apache, давайте сначала определим, что такое обратный прокси и почему он нам нужен. Пожалуйста, имейте в виду, что следующее описание отражает мое понимание, и я прочитал много разных интерпретаций, так что хочу убедиться, что мы все на одной волне.
Обратный прокси — это Instance, который принимает запросы от клиентов и перенаправляет их на Instance в backend. Ответы от backend затем передаются обратно на обратный прокси, а оттуда — клиенту. Это означает, что клиент никогда не знает, что он общается с Instance backend — вся коммуникация туннелируется через обратный прокси.
Из-за этой особенности обратный прокси является идеальным дополнением к нашему сетапу — мы можем развертывать столько VNC-инстансов, сколько захотим, а обратный прокси обрабатывает все запросы разных пользователей. Это сэкономит нам множество открытых портов и упростит обнаружение потенциально других инстансов noVNC. Итак, как мы можем его настроить?
Поскольку я новичок в технологиях веб-серверов, я решил попробовать свои силы с Apache. Здесь было довольно просто использовать VirtualHosts в файле 000-default.conf. Вот пример конфигурации, которую я создал:
Код:
NameVirtualHost *
<VirtualHost *:80>
<Location /5b6fefd758e9f1fd8dcf0fe2cc6c>
ProxyPass http://172.17.0.2:6901
ProxyPassReverse http://172.17.0.2:6901
</Location>
<Location /5b6fefd758e9f1fd8dcf0fe2cc6c/websockify>
ProxyPass ws://172.17.0.2:6901/websockify
ProxyPassReverse ws://172.17.0.2:6901/websockify
</Location>
</VirtualHost>Вы заметите, что вместо поддоменов я решил использовать подкаталоги в обратном прокси. Это гарантирует, что наш сетап требует только одного имени хоста и каждый подкаталог перенаправляет на один контейнер noVNC. Это было сделано для того, чтобы сэкономить на работе и DNS-записях.
Но нам нужно больше, чем просто перенаправление к правильному контейнеру, поскольку соединения noVNC зависят от веб-сокетов, и поэтому нам также нужно перенаправлять эти соединения. Это делается с помощью записи
ws://172.17.0.2:6901/websockify.В принципе, это все, что требуется для настройки обратного прокси, что замечательно, потому что это очень просто и легко для понимания (что было очень важно, так как мне нужно было это понять).
Итак, мы разобрали все — в Apache мы используем модули прокси для достижения необходимого перенаправления. Мы настраиваем 000-default.conf для перенаправления наших соединений на соответствующие контейнеры VNC, и на этом всё.
Кроме того, эта конфигурация может быть также легко применена к контейнеру Docker, что идеально подходит для перехода к инструменту / скрипту, который я написал в качестве учебного опыта.
NoPhish - инструмент / настройка.
Итак, сочетая все вышеперечисленное, я представляю вам NoPhish. По сути, это полноценная фишинг-настройка на базе Docker, которая использует noVNC.
У нас есть образ Docker для наших контейнеров noVNC, который будет запускаться для каждого пользователя, которого мы хотим фишить, и один контейнер обратного прокси, который будет обрабатывать все входящие запросы и распределять их между различными контейнерами.
Кроме того, система будет извлекать все собранные куки (и куки сессий) из запущенных контейнеров noVNC — это происходит каждые 60 секунд. Результатом этого являются файлы cookies.json (для удобного импорта в предпочитаемое вами расширение).
Итак, это общее представление о cbcntvt и механизмах — теперь краткий обзор того, как это использовать.
Установка
Чтобы настроить инструмент, необходимо выполнить следующие требования:
- Docker должен быть установлен.
- Для экспорта куки требуются модули Python lz4 и json.
Когда эти требования выполнены, клонируйте репозиторий и выполните setup.sh:
setup.sh installТаким образом, за кулисами этого волшебного bash-скрипта будут созданы образы Docker (на основе предоставленных Dockerfile). Затем мы можем начинать.
Запусти это!
Когда установка завершена (или если вы хотите начать новое вовлечение), вы можете запустить всю инфраструктуру с помощью скрипта setup.sh.
Вот краткий обзор параметров:
Код:
Usage: ./setup.sh -u No. Users -d Domain -t Target
-u Number of users - please note for every user a container is spawned so don't go crazy
-d Domain which is used for phishing
-t Target website which should be displayed for the user
-e Export format
-s true / false if ssl is required - if ssl is set crt and key file are needed
-c Full path to the crt file of the ssl certificate
-k Full path to the key file of the ssl certificateИтак, всё понятно — тогда мы можем запустить это:
Код:
./setup.sh -u 4 -t https://accounts.google.com -d hello.localЭто запустит 4 VNC контейнера Docker (по одному для каждого пользователя), которые будут нацелены на URL
https://accounts.google.com под доменом hello.local (да, не лучший выбор, но это тест).Система также поддерживает SSL; вам нужно только предоставить сертификат и ключ, и тогда она будет работать с HTTPS на порту 443. Если они не предоставлены, система будет работать с HTTP на порту 80.
Когда настройка начнется, она покажет вам следующий вывод:
Код:
./setup.sh -u 4 -t https://accounts.google.com -d hello.local
[+] Configuration file generated
[-] Starting containers
[+] VNC Containers started
[-] Starting reverse proxy
[+] Reverse proxy running
[+] Setup completed
[+] Use the following URLs:
http://hello.local/f325a55604e4d31f5a469d591e2c/conn.html?path=/f325a55604e4d31f5a469d591e2c/websockify&password=f325a55604e4d31f5a469d591e2c&autoconnect=true&resize=remote
http://hello.local/25fcc33508ad8abecac8259223a7/conn.html?path=/25fcc33508ad8abecac8259223a7/websockify&password=25fcc33508ad8abecac8259223a7&autoconnect=true&resize=remote
http://hello.local/7eb3f7dd95feb93ff5ad653e6920/conn.html?path=/7eb3f7dd95feb93ff5ad653e6920/websockify&password=7eb3f7dd95feb93ff5ad653e6920&autoconnect=true&resize=remote
http://hello.local/695ad1ff254ee7806b06835d6b3d/conn.html?path=/695ad1ff254ee7806b06835d6b3d/websockify&password=695ad1ff254ee7806b06835d6b3d&autoconnect=true&resize=remote
[-] Starting Loop to collect sessions and cookies from containers
Every 60 Seconds Cookies and Sessions are exported - Press [CTRL+C] to stop..
^C
[-] Import stealed session and cookie JSON to impersonate user
[-] VNC and Rev-Proxy container will be removed
[+] Done!Отображаемые URL-адреса для фишинга содержат случайные строки (в этом примере f325a55604e4d31f5a469d591e2c) — это должно обеспечить некоторую случайность в URL (чтобы заманить пользователя), скрыть VNC-соединения от сканеров и рандомизировать пароль VNC.
Затем скрипт начнет свой цикл для сбора куки и сессий. Чтобы не углубляться в слишком много деталей (потому что именно эта часть всего мероприятия чуть не довела меня до безумия) — цикл включает в себя следующие шаги:
- Копия recovery.jsonlz4 и cookies.sqlite каждого контейнера noVNC.
- Извлечение информации о сессиях и куках из этих файлов.
- Импорт информации в phis.db (в данный момент это делается только для документирования собранной информации и для того, чтобы другие могли создать пользовательский вывод).
- Создание двух .json файлов — одного для сессий и одного для куков.
Хорошо, возможно, немного инсайта — здесь сыграла роль моя упрямство. Контейнер noVNC использует Firefox в качестве браузера. Firefox обрабатывает сессионные куки и обычные куки по-разному. Обычные куки сохраняются в файле cookies.sqlite — легко читаемом и понятном. Сессионные куки сохраняются в памяти (лучше защищены, но не так хороши для нашей цели). Первоначальная реакция заключалась бы в том, чтобы использовать Chromium (который обрабатывает куки и сессионные куки иначе, чем Firefox), но я хотел найти способ с Firefox. После долгих поисков в Google (и переосмысления жизненных выборов) я наткнулся на файл recovery.jsonlz4. Этот файл создается Firefox для сохранения текущего состояния браузера, чтобы обеспечить его восстановление в случае сбоя — и он также содержит сессионные куки
.Вот почему в системе есть два скрипта, которые занимаются различными частями информации о пользовательской сессии. Каждый скрипт создаст отдельный JSON-файл (
cookies.json и session.json) — формат обоих файлов одинаковый.Что касается формата JSON-файлов, настройка предлагает возможность создать простой файл
cookies.json с помощью опции -e simple (хорошо подходит для использования с расширением CookieBro). По умолчанию скрипт будет генерировать пользовательский формат cookies.json, который совместим с Cookie Quick Manager для Firefox.И это всё — вот как вы можете запустить инструмент.
Останови это!
Хорошо, вы провели свой отличный фишинг-тест — получили права администратора домена и так далее. Но что делать, чтобы остановить и удалить инфраструктуру?
Во время выполнения, если вы нажмете
ctrl + c, скрипт остановится и удалит все созданные Docker-контейнеры. Если вы хотите полностью удалить Docker-образы, просто выполните ./setup.sh cleanup — в этом случае скрипт снова попытается удалить контейнеры и дополнительно удалит все Docker-образы. Имейте в виду, что перед тем, как снова использовать настройку, вам нужно будет установить ее снова.Заключение
Надеюсь, я смог дать вам некоторое представление о данной фишинг-системе и более глубокое понимание того, как использовать noVNC в рамках фишинговой кампании. Пожалуйста, дайте знать, если инструмент/настройка (NoPhish) как-то помогли вам, что можно было бы сделать лучше, а @моему-будущему-я, надеюсь, ты снова вспомнил, как работает твой собственный инструмент.