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

Support Our Threat Intelligence

If you find our technology report and cybersecurity news helpful, consider supporting our work.

Buy Me a Coffee PayPal Crypto

USDT (TRC20):

TN8BdV8cp4T1Cd28gK9qTAnZknzzuwyUtm Copy

USDT (ERC20):

0x3725e1a7d3bc5765499fa6aaafe307fabcd75bce Copy