As an increasing number of people depend on digital communication in their everyday routines, the risk of cyber-attacks grows in significance. One type of attack that is becoming more prevalent is the Adversary in-the-middle (AiTM) phishing attack.
At PSI, we have a strong specialization in this area, and with this introductory post we intend to start a series of blog posts focused on phishing attacks.
The good old phishing
The method of executing phishing attacks has been widely recognised for quite some time now. It involves Malice contacting Alice, typically through email, SMS, or other means, and presenting her with a link to click on. The link directs Alice to a website created by Malice, which closely mimics the appearance of the original page. Once Alice enters her sensitive information, the website logs it for Malice's use.
Exposing a typical phishing site is rather simple. Closely examining the address bar could already provide a significant hint about the authenticity of the website. Interacting with the web page, clicking buttons or submitting fake info is sufficient to detect that something looks suspicious. For instance, entering incorrect login credentials and observing whether the site displays any error. Alternatively, browsing to different paths. Typical phishing pages are served over a path and not at the root of the site. If one tries to visit the root, there will most likely be an error or a completely different website.
Phishing attacks can be much more advanced than merely collecting credit card numbers, passwords, and other sensitive information. With the introduction of increasingly robust security mechanisms such as two-factor authentication, standard phishing techniques are no longer effective. Credentials, for example, are useless without a two-factor authentication code.
As a result, phishing attacks evolved into something more dynamic: the AiTM (Attack in The Middle) phishing attacks.
The AiTM phishing attack derives its name from its classification within the "in-the-middle" family of techniques, where Malice, in this case the phisher, intercepts and manipulates communication between Alice and Bob, the target website.
How AiTM works?
To understand this type of variation, it is important to to clarify the context. We find ourselves in the World Wide Web (WWW), where Alice, Bob, and Malice are not on the same network. Well-known MiTM attacks are not realistic in this situation. The only practical way for Malice to intercept communication between Alice and Bob is to trick Alice into believing that Malice is Bob.
The method by which Malice approaches Alice is similar to the "old days phishing," but the landing page has changed. Instead of hosting a clone of the actual website, it now hosts a web proxy, which is the heart of this attack technique and where all the magic happens. The goal of this technique is not only to collect credentials, but also to surf the victim's session and go beyond merely stealing login information and credit card details.
AiTM phishing attacks are based on special web proxies. Web proxies are servers that act as intermediaries between a user's device and the real destination. They can be used for various purposes, such as improving web browsing speed, accessing restricted content, or enhancing online privacy.
The use of web proxies dates back to the early days of the World Wide Web, around the mid-1990s. They were originally designed to cache frequently accessed web pages, reducing the load on web servers and speeding up access for users. Over time, the role of web proxies has expanded to include a wide range of functions, such as content filtering, anonymous browsing, and data protection. Today, web proxies can also be used for phishing attacks.
In AiTM phishing attacks, Malice, who serves as the proxy, is nearly transparent. It functions as a web server for Alice, waiting for her connections and collecting all the necessary information. Then, Malice switches to being a client and forwards the received connections to Bob. When Bob responds, Malice captures all the required information and returns Bob's response to Alice.
Note that this works transparently with TLS, without the need to intercept. Since the proxy is acting as both a server and a client, there is full control of the traffic under the TLS layer.
By operating in this manner, it becomes clear that there is no longer a need to replicate pages or manually modify web forms, since Malice is essentially intercepting all the traffic between Alice and Bob. If Alice employs the same techniques described before to detect ~90% of phishing sites, nothing will appear unusual, except for the URL.
AiTM in detail
While the attack flow in an AiTM phishing attack is straightforward, the implementation is not as straightforward. The reason for this is because using a standard transparent proxy will not suffice.
The Web is a vast and wild place, but fortunately, many good people work to ensure the security of Internet users. Web security, as described in the Web Security documentation, is an essential topic. Simply acting as a transparent proxy would violate many security rules, and it would render communication between Alice and Bob impossible.
For the phishing attack to succeed, the proxy needs to be almost-transparent. This requires altering both the requests and responses in a smart way.
Specifically, in the request flow from Alice to Bob, it's critical to ensure that the phishing domain is not revealed to the legitimate domain. Therefore, any mention of the fraudulent domain must be substituted with the appropriate legitimate domain. In general, the key components that could disclose this information are:
Request URI, specifically the Request Target, with the absolute path and query string components.
Header Fields
Referer
Origin
Cookie
X-Forwarded-For
...
Message Body
After Bob responds, the proxy must send the message back to Alice, which constitutes the response. The main focus at this stage is to eliminate any reference to the genuine website. As with the request, among the affected elements we can find:
Header Fields
Access-Control-Allow-Origin
Content-Security-Policy
Content-Security-Policy-Report-Only
Location
Referrer-Policy
Set-Cookie
WWW-Authenticate
X-Frame-Options
...
Message Body here there are references to CSS, JavaScript, images, etc. that need to be converted accordingly
It goes without saying that the request and response elements mentioned before are the “standard” ones, but nothing prevents a website to serve custom header fields or message body. Consequently, the attacker must adjust these elements to prevent any form of data exposure or violation of web security policies. Speaking about security policies, the proxy can actually downgrade the client security by relaxing or completely removing the Content-Security-Policy and X-Frame-Options headers.
Having introduced the basic concept of this type of proxy, let's consider an example of a static webpage: example.com. By implementing the modifications discussed earlier, our phishing proxy, hosted at phishing.click, can intercept requests and responses and display the webpage correctly.
As illustrated below, the sole link on the page directs to www.iana.org. However, if the phishing proxy fails to alter the Referer HTTP header, iana.org will record in its logs that one of its resources was requested from phishing.click.
This technique may work seamlessly when the phishing attack targets a website that is hosted on a single domain, with no subdomains or external resources involved, which is unlikely in practice. When the phishing proxy encounters multiple subdomains and external domains, a significant level of expertise is necessary to overcome the various web security barriers.
As another example, phishing.click is attempting to conduct an AiTM attack on github.com's signup flow. However, github.com employs octocaptcha.com as an external domain for captcha challenges and the signup flow is stopped by an error with the Captcha response. The reason for this is evident in the console logs. The Content Security Policy of octocaptcha.com prohibits it from being framed by phishing.click, causing the browser to halt and disrupting the flow. Consequently, the victim is unable to proceed any further.
However, if octocaptcha.com gets properly proxied, the entire flow works without any hiccups.
The crucial role of proper traffic interception
At this stage, the real challenge is to determine how to effectively intercept all the required origins and avoid any possible errors that would break the request flow.
So far, it was observed that the phishing proxy links the phishing domain to the target domain, by mapping phishing.click to github.com, and adjusts the HTTP requests and responses accordingly. Nevertheless, github.com differs from its subdomains and external origins in various ways. This implies that a phishing domain would be required for each origin. For instance:
www.phishing.click for www.github.com
api.phishing.click for api.github.com
another-phishing-domain.tld for octocaptcha.com
At this point, to a discerning reader, it becomes evident that accommodating a single phishing campaign can require multiple instances and configurations, leading to a never-ending cycle of servers and settings.
Now is the time for automation and tools to take action. With several potential solutions available to address this issue, let's explore how our open-source phishing proxy, Muraena, tackles the problem.
Mapping the origins
Muraena goes beyond the basic set of features expected of a proxy and has been specifically designed to manage various origins by linking each relevant domain to a subdomain of the phishing domain. The domains of interest include those needed for the standard request flow, as well as those containing sensitive information.
The initial mapping is easy and involves linking the victim's domain subdomains, such as the case with github.com as the target:
www.github.com is www.phishing.click
api.github.com is api.phishing.click
xyz.github.com is xyz.phishing.click
...
In essence, all subdomains of github.com will be linked to corresponding subdomains of phishing.click: *.github.com to *.phishing.click. The next mapping handles all the external origins:
octocaptcha.com is www-1.phishing.click
github.githubassets.com is www-2.phishing.click
avatars.githubusercontent.com is www-3.phishing.click
...
As evident, subdomain mapping follows a one-to-one approach, whereas external origins necessitate a distinct approach. Muraena uses a customisable subdomain prefix, such as www- in this case, accompanied by a unique numeric identifier. The identifier is internally resolved by the tool and adjusted based on requests and responses. This comes handy to proxy origins with an arbitrary number of subdomains and still use a standard wildcard TLS certificate for the phishing domain, which covers only one level of domain nesting.
The final aspect to address pertains to configuring the DNS records, which guarantees that the phishing domain and its subdomains lead to the proxy. The process is straightforward, as only two A records need to be set up:
A record named @ and pointing to the proxy IP
A record named * and pointing to the proxy IP
The initial record pertains to the root domain, specifically phishing.click, while the latter is a wildcard record that encompasses all of its subdomains.
Conclusion
In conclusion, merely proxying a single domain is insufficient for executing a sophisticated phishing campaign. Intercepting all the involved origins, whether internal or external, is essential for a seamless flow and, more crucially, preventing information leakage. In the upcoming posts, we will explore the process of mapping the attack surface and customising Muraena. Additionally, we will delve into automating the post-exploitation process and enhancing operational security.
Until next time.