About This Project
Background
At 0xda7a, we are regularly asked how easy it actually is to "clone" a website in order to phish for credentials. These questions usually come from executives whose focus is not in IT. When we answer that it is quite easy to clone the login portal of their own platform, many respond with: "but we have multi-factor authentication, so an attacker still can't get in even with a phished password".
However, very few people are aware that one-time codes via SMS or email, TOTP (time-based one-time passwords, which are usually generated in authenticator apps) or custom-built solutions where you scan QR codes on the website with a self-developed authenticator app, are not resistant to phishing.
Many developers nowadays know that rate-limiting for login attempts, brute-force-resistant algorithms for password hashing, and sensible policies for creating passwords need to be implemented.
But when it comes to "multi-factor authentication" - either because it sounds good from a marketing perspective or because you need to tick a box on a framework checklist - the simplest solution is usually implemented.
People resort to those non-phishing-resistant methods. That is, methods where the second factor is either entered directly into the website or confirmed on a separate device.
And that is exactly the problem: these MFA methods are completely independent of the website's domain. This allows an attacker to simply set up a proxy on a similar domain of their own and trick the victim into visiting the site.
The proxy forwards all requests to the real website and waits for the victim to log in and complete the MFA step. The real website then creates an authenticated session and sends session cookies through the proxy to the victim's browser. The attacker only needs to record the session cookies with the proxy and can then use them later to access an authenticated session of the victim on the real website.
Further technical explanations can be found here: Adversary-in-the-Middle Kits: What they are and what makes them so dangerous
A demonstration says more than a thousand words - that is why we built this tool to provide website developers and non-technical people with a simple way to test how resistant their own website is against modern phishing methods.
Implementation
The entire project is written in Rust - both the proxy and this website.
The reverse proxy is built on Pingora by Cloudflare.
As soon as a user enters a domain to test, the target site is served through the proxy.
Hostnames are extracted on-the-fly from the HTTP responses and automatically mapped to subdomains of this-is-not-the-real-web.site -
for example 1.this-is-not-the-real-web.site to example.com2.this-is-not-the-real-web.site to cdn.example.com,
and so on.
This domain mapping is then used to replace the domains in the requests and responses between the browser and the proxy, as well as between the proxy and the real website.
Additionally, various security-related headers are removed or modified so that the browser actually displays the proxied page.
To prevent abuse, each proxy session is bound to the client IP and the TLS fingerprint (JA4) of the visitor.
This way we can uniquely identify the client and always select the correct domain mapping.
All subdomains of this-is-not-the-real-web.site are multiplexed across individual sessions:
For one user, 1.this-is-not-the-real-web.site may point to google.com, while the same subdomain for another visitor points to duckduckgo.com.
The website itself is built with Leptos - a web framework for Rust.
Contact
Questions, feedback, or security concerns? Write to hello@0xda7a.com.