EvilKnievelnoVNC: Scalable and semi-automated MFA-Phishing

Weaponized EvilnoVNC: scalable and semi-automated MFA-Phishing via “browser-in-the-middle”

Features

• concurrent EvilnoVNC instances, as many as your server can handle
• access to EvilnoVNC sessions is limited to generated URLs with random victim-specific identifier in parameter
• auto block users after successful authentication, presenting a custom message/page
• manipulate target site via Chromium extension, e.g. hide alternative login methods such as hardware token, or perform any action in the name of the victim
• admin dashboard
  • monitor active victims in real-time
  • react on victim’s actions: view session, overtake (authenticated) session or reset session
  • overview of phishing campaign progress
  • collected credentials
• dynamic resolution mode with preloading page is currently the default
• victims can paste text to noVNC via dirty trick
• a victim’s user agent is replicated

Technical Overview

• Running on multiple Docker containers with internal networking
• HAproxy used as loadbalancer and gatekeeper
• nginx for simple dashboard
• victim data and statistics is stored in a central targets.json
• Chromium extension inside noVNC that monitors the victim’s activity

Use

• when running EvilKnievelnoVNC the admin dashboard is reachable via the defined URL and basic auth credentials (/phishboard)
• by default a self-signed TLS certificate will be presented (CN: testing-server) with the following fingerprints
  • sha1 AE:28:1B:05:5B:C0:55:41:22:DA:7C:6F:D2:51:8D:D1:11:B2:7C:21
  • sha256 D0:B6:9D:86:6D:AE:B4:E1:CA:F0:C1:F5:4D:82:45:7E:13:06:CD:1A:DE:49:A3:80:DC:21:6A:5C:A8:F4:84:1B
  • place your own TLS certificate, define location in setup.sh
• configure victims in the dashboard via “Manage Targets”
  • add an email address per victim
• send the generated URLs to the victims and monitor the activity in the dashboard
• caution
  • use responsibly and only in legal manners
  • there is no guarantee for anything, check the code and test it before usage

Advanced Usage

• victim actions are logged to accesslog.txt and submitlog.txt
• keylog, decrypted cookies, Chromium profile and downloads are put in the central Loot directory (docker volume)
• consider running controller and haproxy manually with their respective run.sh for debugging and insights
  • there needs to be at least another container running before haproxy is started! (haproxy limitation)
• consider customizing the name of the identifier URL parameter (haproxy/haproxy.cfg and controller/src//.php)
  • with some adjustments, it can be placed in the path of the URL as well

Install