Evilginx: An Appropriately Named AiTM Tool
This is me finally finishing a blog post that I started the first time I was experimenting with Evilginx back in January of 2024. As you can tell, this post is just a bit overdue...
What is Evilginx?
Evilginx is a tool developed by Kuba Gretzky that can be very useful to someone wanting to create their own customized phishing test for users at their workplace, or for someone conducting a red team engagement or penetration test who wants to get some easy wins by sending phishing emails to users. As always with cybersecurity and hacking, these tools and methods are only meant to be used against people and devices you've got explicit permission to attack.
With the above description, you're probably curious about how Evilginx works. At a basic level (which is realistically as deep as I could get into the actual inner workings of this), Evilginx works by taking a domain you control and using it as a proxy to funnel legitimate login attempts through your server—where Evilginx is installed—before the traffic is sent to the legitimate destination. Hence, the designation as an "Attacker in the Middle" (AitM) attack.
For the end user, if they aren't paying close attention to the link they're clicking on, they may never notice that they've fallen for a malicious link. This is especially dangerous if the attacker is able to secure a domain that's close to the target’s URL.
A good way to think of this is imagining your target is something like Super Secure Billing at www.supersecurebilling.com, and you are able to get the domain www.supersecurebillingIT.com registered to yourself. The average user is just going to see "Super Secure Billing" and assume it's all the same and safe to click on. Similarly, attackers can take advantage of misspellings that may be difficult to see at a glance. If you were able to register www.supersecurebiilling.com and use that (did you catch the misspelled part on your first read through?) in your attack, users might well just see an address that looks similar and not notice the difference in spelling. These are all ways to make it more likely that users at a company click on your links and submit their information without realizing it until it’s too late. (Again, only do this to targets you're allowed to test against.)
After a successful login attempt by users, they are redirected to a page of your choice (you could use a legitimate page from their company site so, at most, they think their login just didn’t work), and they likely remain unaware that they fell for a malicious link.
Meanwhile, on the back end, you are presented with the user's username and password in plain text—but even better, the session cookies are available to you, even if they used MFA to log in. This means you can take that session information and, using a cookie editor with your browser of choice, sign in as that user—with access lasting as long as the session remains valid. If their company has lax security, that session could be valid for days, meaning you've got access to anything they have access to. If they’re using the Office suite, you could have access to all manner of sensitive documents and files, which you can quickly begin reviewing for more information to help in your attack.
Part 1: Registering a Domain
The easiest part is registering a domain to use. If you're doing this for your company, this is a good time to see what domains similar to your company’s might be available for purchase. If you have any alerts configured for domain names purchased using keywords tied to your company, this will be another thing to test. If you pick something close to your company name, you can check if it triggers the expected alerts in your system. Another thing to check for—which initially threw up a roadblock for my testing—is any blocks your team may have for newly seen domains. We have that configured, and in my initial tests I ran into issues until I went in and made an exception for my domain.
You can use any domain registrar you want. I just went to Squarespace to get a domain since I already had one through them for this very blog. With the domain purchased, all that was left for me to do was to make sure that instead of pointing to Squarespace's name servers which would normally be useful if you're hosting everything through them, we need to point internet traffic to our server that's hosted somewhere else, independent of Squarespace. For this, we just need to clear any of the default DNS configurations for Squarespace and then go to the DNS Nameserver section where we can input the ns1 and ns2 nameservers for Digitalocean as seen in the images below.
Part 2: Configuring DNS on Your Hosting Platform
Before we dive into the configuration, we’ll stick with the DNS theme and configure our DNS at DigitalOcean (or wherever you’re hosting your box). The specifics may be slightly different but the overall idea should be the same with whichever provider you've selected.
In DigitalOcean, head to the Manage drop-down menu on the left side of the page, and select Networking. In the main body of the page, you’ll see the Domain section, where you can configure everything to point to your server. We’ll dive into the server setup shortly, but once it's configured, you should have an external IP address associated with it. You’ll want to copy this IP—it’s what you'll use for your DNS records. Under Domain, you'll need to create a domain for your purchased nameserver. In this example, we’ll use the domain name of this blog (idiotit.com) and a fake IP space, since by the time this is published, the server will likely be gone. We need to create a few types of records. First, point your domain to the name servers for DigitalOcean. This involves configuring three different name servers, pointing just the domain itself (without www. in front. I made this mistake initially, so save yourself that struggle.).
In our case, that would mean creating three NS records for idiotit.com, pointing to:
- ns1.digitalocean.com
- ns2.digitalocean.com
- ns3.digitalocean.com
- www.idiotit.com → points to your server's external IP address (e.g., 123.456.789.123)
- login.idiotit.com → also points to the same IP
- admin.idiotit.com → again, points to the same IP
Once you are finished your DNS configuration should look something like what's pictured below. You'll have A records for the specific subdomains of admin, login and www that point traffic to your specific DigitalOcean VM IP address and then name server records that tell traffic to check with the DigitalOcean nameservers to figure out where that is while looking for your domain on the internet.
Part 3: Configuring Your Virtual Machine
On the DigitalOcean site, you can easily create a virtual machine server (called Droplets in their terminology) using their deployment tools. Start by going to the Manage drop-down menu on the left again, and this time select Droplets. Click Create Droplet in the top-right corner of the body window. From there, you can select the configuration you want for your VM.
First, choose the region where you want your VM deployed. It’s a good idea to pick a region near you to limit latency during use. As for the Droplet configuration, you don’t need a powerful machine to run Evilginx, and you don’t need much storage either. (To clarify: in my case, we’re only doing small-scale testing, so we don’t need a lot of space or horsepower. If you're planning to send out many different links for various phishlets or expect heavy traffic, you may need to scale up the configuration. Fortunately, DigitalOcean makes it easy to monitor usage and performance, which helps when troubleshooting.)
Our deployment uses a Basic droplet type with the Debian 12 x64 version.
(Another note: you can upload custom images if you’d like, and there are other specialized offerings in the Marketplace.) For this deployment, we’re using the $4/month configuration, which includes:
- 512MB RAM / 1 CPU
- 10GB SSD disk space
- 500GB of transfer bandwidth
Part 4: Installing Evilginx
We've finally arrived at the fun part. Well, I guess it's more so the precursor to the fun part. This is where we will actually get Evilginx installed and get the Debian OS configured to allow Evilginx to work properly. Fortunately for us, there's a lot of great documentation via blogs, but also on the Evilginx website where you can get installation instructions for the open source version and the paid professional one. Fortunately for us, there is an easy way to install Evilginx using the Kali repositories. Our first order of business will be to configure the Droplet to allow us to utilize that.
Configuring Droplet to Allow Installation from Kali Repositories:
To see if we already have the Kali repositories available on our system we can run:
cat /etc/apt/sources.list If we don't see anything, following the instructions from the Kali Linux guide on switching branches we can add the rolling branch which is the most frequently updated, or the last-snapshot version that is more stable and safer. Since we're living on the edge today, we'll just go ahead and add the kali-rolling version using the following command:
echo "deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware" | sudo tee /etc/apt/sources.listUpdating Linux Packages:
sudo apt update
sudo apt upgrade
sudo apt install kali-defaultsInstalling Evilginx from Kali repositories:
sudo apt install evilginx2Creating a New User:
With everything setup for us we can go ahead and add a new user so we aren't always logged in as root. We are supposed to be safety conscious after all, right? To do this we just need to run the following command:
useradd -G sudo -m -s /bin/bash typeyournamehereSome notes for the flags in the command above:
useradd - The command we need to add a user to the system.-G sudo - This flag will add the user to the sudo users group.-m - This flag creates a home directory for the new user in /home/typeyournamehere.-s /bin/bash - This flag sets the user's default shell to Bash.typeyournamehere - This is where you give the user the name you want. I guess if you want them named typeyournameherethat's up to you.Lastly, all that's left for us to do is make sure we configure things to allow Evilginx to use Port 53 for DNS. There's a check whenever you first launch Evilginx for this and it will throw an error message at you if it's not configured right, which can make it difficult to determine if your machine isn't allowing access to Port 53 or if you've somehow misconfigured your DNS settings. To do this we will want to run the following command which will open the resolved.conf file on the system using Nano (you can use any text editor you prefer, but Nano is generally already installed and we don't have a ton of editing to do):
sudo nano /etc/systemd/resolved.confOnce that's open we will want to remove the comment character from in front of a few lines in the file to allow those settings to be used by the system (the # character would otherwise tell the system to ignore those lines). When you see the following lines in the configuration just make sure there's no # at the start of the line and make sure the line matches what we have configured here:
DNS=8.8.8.8FallbackDNS=1.1.1.1DNSStubListener=noOther than those 3 options you can ignore the others and hit Ctrl + x to save the file. Lastly, we just need to do one final thing for the DNS setup we just created, which is to create a symbolic link from the DNS resolver config from our system (resolv.conf) to the DNS file that's managed by systemd-resolved.
To do this we just need to run:
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.confThis will create a symbolic link from the system DNS file to the one we just edited.
End of the Road:
And that should be the end of the initial system setup and configuring our domain and Droplet (VM). With all of this done, we should be ready to fire up Evilginx and start configuring things to test out against users through whatever means we want to use to get the link onto their computers. The easiest way to achieve this would be to email them a link directly. With Evilginx you'll be able to setup different links for different types of logins. If you want to capture credentials from a company that predominantly uses Microsoft logins you can use the o365 Phishlet. But we'll get more into that side of things in the next blog post where we actually start to use Evilginx and get to see just how dangerous it can be.
Until next time, stay safe!
Comments
Post a Comment