Author

Jim Gogolinski

Head of Threat Research

Category

Conceal Recon Group

Published On

Jan 13, 2026

Conceal vs EvilGinx

This blog will be the first entry in a new series of “Conceal vs”. In this series, we will discuss various threat-actor TTPs (tools, tactics, and procedures), how they work, why they work, who might be using them, and how Conceal’s real-time browser-native security solution thwarts them.  Throughout this series, we will find a subset of tools and projects designed to help white-hat hackers, red teamers, and general security auditing teams keep adversaries outside corporate walls. Unfortunately, these tools are being reused and repurposed for malicious intent. We will ensure that throughout this series, we draw a distinction between legitimate tools used maliciously and those designed solely for misuse.

We will start this series by discussing EvilGinx. EvilGinx was designed for phishing evaluations and falls into the AiTM (adversary-in-the-middle) category.

AiTM is an attack technique in which a threat actor intercepts network traffic between two unsuspecting parties to steal or modify information. What makes AiTM attacks so dangerous is if the attacker handles their infrastructure properly, the information presented in victim’s browser is identical to what they would see in a legitimate login sequence. AiTM toolkits function as proxies with enhanced data interception and modification capabilities.

The following illustrates what is happening in an AiTM phishing attack.

In this attack the unsuspecting user receives a phishing attack (via email or a webpage) and clicks the malicious URL. This URL is likely disguised to look very similar to what the victim would expect for their normal account verification activities. Often, these phishing attacks convey urgency, which can make victims less likely to carefully inspect the URL and more likely to click, as they feel pressured to complete the task as soon as possible. What the user expects to happen is a communicate directly with the legitimate credential server (6). In an AiTM attack, the URL (1) redirects to an attacker-controlled AiTM proxy. The AiTM proxy is configured to send a request to the legitimate credential service provider (2). The credential service provider has no way of knowing that this is an AiTM attack and responds as normal to the attacker-controlled AiTM proxy (3). The AiTM proxy then forwards this page directly back to the victim (4), so the page contents are identical as if the user followed path 6. Any follow-on communications, such as password resets and MFA, are routed through the 5, 2, 3, 4 cycle. While all of this is happening, the AiTM proxy extracts the login credentials sent by the victim and any session cookies from the credential provider. Once the login transaction is complete, the unsuspecting victim will be sent to their destination, whether it’s email, a document, or something else. Advanced threat actors will ensure that the user ends at a legitimate destination to not arouse suspicion if they end up at a spot they were not expecting.

Tools like EvilGinx make this easier than ever. Here’s how simple it can be:

Once you understand how to configure EvilGinx, the hardest part of the job is creating a believable lure email. There’s other work involved, like registering a new domain for the proxy server, for example, but that’s trivial for advanced threat actors. Many will already have domains registered and owned, just waiting for the right opportunity to be used against a specific target.

As mentioned earlier, EvilGinx will capture username/email, password, session auth tokens, etc. Here’s a redacted sample of data that EvilGinx captures.

Unfortunately, versions of EvilGinx are freely available for download from multiple GitHub repositories, and there is a significant amount of tutorial and how-to information online.  There is also a strong possibility that many advanced threat actor groups may purchase the latest professional versions through front companies to conceal their true identities. AiTM attacks, when executed against the proper targets, make gaining access to a corporation very easy. Obtaining valid credentials allows attackers to gain access to the network without resorting to vulnerabilities, which makes detection even more difficult.

With that as background on EvilGinx, let’s dive into an actual incident. As is typical, this incident began with an email from a legitimate, albeit compromised, account. The initial link sent the victim to the following page:

 Clicking on the “Click here to view document” brings the user to the actual EvilGinx page:

hxxps://southwestbuiilding[.]com/ngFoVCSq

This URL format is typical of an EvilGinx lure, a domain followed by an alpha sequence. There are other subdomains that also ultimately resolve to that URL. That URL then redirects to the following URL – notice it is the same layout as an official Microsoft login redirect and uses identical URL parameters.

hxxps://southwestbuiilding[.]com/common/oauth2/v2.0/authorize?client_id=4765445b-32c6-49b0-83e6-1d93765276ca&redirect_uri=https%3A%2F%2Fwww.office.com%2Flandingv2&response_type=code%20id_token&scope=openid%20profile%20https%3A%2F%2Fwww.office.com%2Fv2%2FOfficeHome.All&response_mode=form_post&nonce=639032297535603349.OTE4Zjc5MmYtMmY0NS00M2Y5LTg2MTAtOWY5MzJlMmIxYmNhYTdjZDJjMDktOWU1NS00YjQwLTlkMzAtZjc3Njk5ODc1MTdl&ui_locales=en-US&mkt=en-US&client-request-id=03bcb988-c251-48a7-9f0e-

What does the actual page look like to the unsuspecting victim? The only tell on this page is the actual URL itself. 

It looks remarkably like a legitimate Microsoft sign-in page because that’s what it is. It’s just being proxied through the southwestbuiilding[.]com web page via EvilGinx. Here’s the DNS registration for that website.

Domain Name: SOUTHWESTBUIILDING.COM

Registry Domain ID: 3035552989_DOMAIN_COM-VRSN

Registrar WHOIS Server:

Registrar URL: http://www.hostinger.com

Updated Date: 2025-11-04T12:54:36Z

Creation Date: 2025-11-04T12:30:30Z

 Registry Expiry Date: 2026-11-04T12:30:30Z

Registrar: HOSTINGER operations, UAB

Registrar IANA ID: 1636

Registrar Abuse Contact Email: abuse-tracker@hostinger.com

Registrar Abuse Contact Phone: +37064503378

Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited

Name Server: MEADOW.NS.CLOUDFLARE.COM

Name Server: RUSTAM.NS.CLOUDFLARE.COM

DNSSEC: unsigned


We can see that it’s not newly registered. Based on EvilGinx's SSL certificate registration process and the available SSL registration data for the domain in question, it appears this site was operational as of November 4th, 2025.  

How Conceal Detected EvilGinx

Conceal stopped EvilGinx in its tracks, preventing a bad day for the user and a worse day for the system administration team.

If the user had selected “Open in Safe Isolation,” they would still have been protected, as isolation is a view-only mode and they would not have been able to enter their username or password.

One of the key differentiators of Conceal’s protection is context. As discussed earlier, the content is not abnormal. It’s a proper Microsoft sign-in page. The danger becomes apparent when we take that content, recognize it as a Microsoft sign-in page, and place it in the context of the environment it's running in. Here’s some of the information you would see when you click on “View Details”.

In the world of two is one and one is none, Conceal identified multiple issues reported on this page.

  1. Conceal made the correct determination that this was an AiTM attack against the user’s Microsoft Credentials

  2. Conceal also noticed that an untrusted site was using images from a trusted authentication service. This is not just using the image; it is using the image in the context of a login page on a site that is not the official login site.

  3. Conceal identified that this site was similar in name to another site, which may indicate it was typosquatting. In almost all phishing training, users are taught to verify the domain to ensure it is correct. Typosquatting relies on the fact that it is “close enough” for most users who are not scrutinizing the domain. Typosquatting is often accompanied by some sort of high-pressure phishing email, causing a sense of urgency in the victim, so “close enough is good enough”.

  4. Conceal found anomalies in the links contained in the HTML.

These are the signatures Conceal used to determine whether to block this page. These signatures consist of a large number of individual checks. Some of these checks, on their own, are sufficient to trigger an action, but most must be combined with other checks to avoid generating false positives. In addition to the checks themselves, Conceal signatures account for DOM modifications, redirects, and more.

Not to be deterred, once southwestbuiilding[.]com was taken down, the threat actor immediately shifted to another compromised site. Although not shown here, Conceal also blocked this page.

This real world AiTM attack was targeting Microsoft credentials. EvilGinx can be used to harvest credentials from platforms such as Facebook, Amazon, Dropbox, and LinkedIn. Many of these platforms already have EvilGinx phishlet configurations available online. Put simply, you can think of phishlets as the configuration files for emulating a particular login provider. If one spends time understanding how EvilGinx works, they can create attacks against any authorization platform. For example, here’s one running against Google.

During this attempt, Conceal detected a Google AiTM attack, a typosquatting attempt, and an untrusted login page.  Conceal also observed network errors on this page, as well as the missing ARIA labels. The network errors are likely indicative of an issue with the Google phishlet being used for this attempt – even though this phishlet was configured incorrectly, Conceal still blocked the attack.

Using advanced DOM analysis techniques and hundreds of individual checks, Conceal stops phishing attacks before any damage is done. Conceal’s unique approach does not rely on a single signal, so it can detect new versions (or older ones, for that matter) without requiring any changes to our extension. This approach is also finely tuned to eliminate false positives, as no one wants to be blocked from legitimate work.