Welcome back! It's been just a couple of weeks since Evilginx release and I'm already swimming in amazing feedback. This encouraged me to spend more time on this project and make it better. The first release was more of a proof of concept, but now I want to make it a full-blown framework, which is going to be easily expandable. In other words, Evilginx is getting modular architecture, easy installation and support for lots of new site templates.

If you want to learn more about Evilginx and how it works, please refer to the previous post, which you can find here.

Looking just for the tool? You can always find it on GitHub at its most current version:

https://github.com/kgretzky/evilginx

Disclaimer: This project is released for educational purposes and should be used only in legitimate penetration testing assignments with written permission from to-be-phished parties.

Evilginx v.1.0 release

This week I'm releasing the product of several weeks of work, which is an official 1.0 release. I've redone some code and put whole Evilginx's functionality into a single script file. Directory structure was reorganized to fit the modular architecture a bit more. From now, site config templates, creds config files and additional config files are organized into separate directories. It should now be easy to add your own templates just by creating new directory in sites directory and populating it with necessary config files. Evilginx will automatically detect site config presence by scanning the directory.

To summarize, here is the list of major additions and fixes:

New site config template system

As mentioned above, the new system makes it very easy to organize site templates and create new ones. All templates should be placed in separate directories under the sites directory.

One-shot fire & forget installation script (Debian only)

No more will you have to perform tedious, manual work like compiling OpenResty, setting up Nginx daemon and gluing all parts together. From now on, the whole Evilginx package can be installed by simply executing install.sh script, which you can find in project's root directory.

Evilginx.py script to setup, parse logs and generate URLs

In root directory you will find evilginx.py script, which, from now on, will act as the command center. It will install/uninstall site configs that you want to enable/disable in Nginx. It will parse the logs, harvesting login credentials and session cookies, while putting them into separate logs directory. It will also generate phishing URLs for you with specified redirection URL, which is now base64 encoded to make it less obvious.

The script, when enabling site templates, will even allow you to set up log parsing to launch every minute. Additionally, it will do the hard job for you by obtaining LetsEncrypt SSL/TLS certificates and it will automatically renew them, keeping them valid for eternity.

New site templates for popular websites

In order to figure out and introduce the structure for modular architecture, I had to create several new templates for new sites. This allowed me to design the base for every template as a foundation of the new template system.

Here is the list of new site config templates, which were introduced with this release:

Facebook

Dropbox

Linkedin

New Google sign-in page

While preparing these, I've encountered several obstacles, that I had to overcome using custom bypasses in LUA code.

Dropbox, for example, had an anti-CSRF protection that required the t parameter to be of same value as the t cookie sent with the same POST request. The POST t value was not set automatically by javascript code if site's URL differed from dropbox.com and that had to be fixed with custom LUA code.

Facebook uses two versions of their site - for desktop and for mobile. If mobile device is detected, user is redirected to m.facebook.com domain, which had to be proxied by adding additional site config file.

New Google sign-in page retrieved external javascript files from ssl.gstatic.com domain, which had to be proxied separately. Otherwise no data was retrieved from the domain, due to strict Access-Control-Allow-Origin rules that disallowed requests from domains not recognized by Google.

If you are interested in creating your own site templates, you may find the included ones very helpful in analyzing how to bypass possible issues you may encounter.

Here is the full CHANGELOG:

version 1.0 : [+] Created central script for handling setup, parsing and generating urls. [+] Added install.sh script that will single-handedly install Evilginx package on Debian. [+] Added support for adding external site templates in framework-like manner. [+] Added sites support for following websites: Facebook, Dropbox, Linkedin and new Google sign-in page. [+] Reorganized code and directory structure to be more accessible for future development. [+] Redirection URLs can now be embedded into phishing URLs using base64 encoding. [+] Setup script allows to enable automatic logs parsing every minute. [+] Setup script automatically handles SSL/TLS certificate retrieval from LetsEncrypt and its renewal. [+] Added regular expressions for parsing POST arguments via .creds config files. [+] Fixed: Opening Evilginx site via HTTP will now properly redirect to HTTPS. [+] Fixed: 'Origin' and 'Referal' HTTP headers are now properly modified. [+] Fixed: Minor bugs and stability issues.

Installation and Usage

I figured it would be wise to give you a rundown of updated Evilginx installation in a step by step manner, on a fresh VPS Debian 8 (jessie) server, which you can easily host on DigitalOcean (this link gives you $10 bonus).

Package installation

SSH to your new server, clone the Evilginx GitHub repository and launch the installation script:

apt-get update apt-get -y install git git clone https://github.com/kgretzky/evilginx.git cd evilginx chmod 700 install.sh ./install.sh

Note for previous Evilginx users: If you want to upgrade your installation, you may need to stop Nginx service first with service nginx stop . Afterwards, you can launch ./install.sh normally.

This should take a while. If all went well, you should be up and running with the whole Evilginx package installed and ready to rock. If it didn't, submit an issue to GitHub's project page and I will take a look.

Now, let's list all available site templates:

python evilginx.py setup -l Listing available supported sites: - dropbox (/root/evilginx/sites/dropbox/config) subdomains: www - google (/root/evilginx/sites/google/config) subdomains: accounts, ssl - facebook (/root/evilginx/sites/facebook/config) subdomains: www, m - linkedin (/root/evilginx/sites/linkedin/config) subdomains: www

For the sake of this tutorial, we will enable phishing site with google site configuration. At this moment you should have already registered a domain that you will use with Evilginx. Let's assume that domain is not-really-google.com . You can register your domain at NameCheap.

Domain setup

You should point your new domain to DigitalOcean's nameservers and specify the A record for your domain on DigitalOcean, which will point to your VPS IP address.

Now is the important part. The listing of available sites includes the subdomains information. This is the list of required subdomains that need to be included in your DNS zone configuration, for Evilgix site config to function properly.

You need to create one CNAME entry for each listed subdomain and point it to your registered domain. For example, google requires two CNAME entries:

accounts.not-really.google.com which will point to not-really-google.com. . ssl.not-really.google.com which will point to not-really-google.com. .

If you do not know how to do any of this, refer to excellent tutorials on DigitalOcean:

Enabling site config

The domain should now be properly set up and all required subdomains should also be pointing at the right place. We can now enable google site configuration for Nginx.

python evilginx.py setup --enable google -d not-really-google.com

The -d not-really-google.com argument specifies the registered domain we own. Follow the prompts, answering Y to every question and Evilginx should enable log auto-parsing and automatically retrieve SSL/TLS certificates from LetsEncrypt using Certbot.

You should verify that all went well, otherwise, you may need to troubleshoot what went wrong and verify that your DNS zones are configured properly. You may also give few hours for DNS settings to propagate as it may not happen instantly.

Generating the phishing URLs

We will now generate our phishing URLs, which can be sent out:

python evilginx.py genurl -s google -r https://www.youtube.com/watch?v=dQw4w9WgXcQ Generated following phishing URLs: : https://accounts.not-really-google.com/ServiceLogin?rc=0aHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g_dj1kUXc0dzlXZ1hjUQ : https://accounts.not-really-google.com/signin/v2/identifier?rc=0aHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g_dj1kUXc0dzlXZ1hjUQ

The -r https://www.youtube.com/watch?v=dQw4w9WgXcQ argument specifies what URL the victim will be redirected to on successful login. In this scenario, it will be a rick'roll video.

As you can see, Evilginx generated two URLs. This is because one is for the old Google sign-in page and the other one is for the new one. You can pick one or the other.

Every minute, Evilginx will be parsing the logs. If anyone got phished and performed a successful login, his login credentials with session cookies will be saved in logs directory under Evilginx root directory.

Session cookies can be imported using EditThisCookie extension for Chrome. If you want to see the whole process, you may want to watch a slightly out-dated demonstration video of Evilginx (all is up-to-date except for shell commands):

Epilogue

I hope this update puts Evilginx on its path to greatness! From now on, I want to focus on adding support for more popular websites. If you happen to succeed in creating your own templates for Evilginx and you want to share, please contact me and I may put your template into official Evilginx repository.

I am constantly looking for interesting projects to work on!

Do not hesitate to contact me if you happen to be working on projects that require:

Reverse Engineering

Development of Security Software

Web / Mobile Application Penetration Testing

Offensive Tools for Red Team Assessments

If you have any feedback or suggestions, contact me via the comment section, via Twitter @mrgretzky or directly via e-mail at kuba@breakdev.org.

Evilginx GitHub Repository

https://github.com/kgretzky/evilginx

Follow me on Twitter if you want to stay up to date.

Stay tuned for more updates and other posts!