chushpan
Professional
- Messages
- 657
- Reaction score
- 447
- Points
- 63
A typical scenario of a social engineering pentest: collected a list of corporate email addresses, set up a tool for conducting phishing mailings, carried out the mailing, obtained employee credentials to access the corporate infrastructure.
The same scenario is typical for many targeted attacks. It still works in some places, but it is losing its effectiveness as awareness programs, email content filtering technologies, and multi-factor authentication (MFA) are implemented.
MFA does not allow an attacker to use a stolen account because a second factor is required to access the data, which remains with the employee. To bypass MFA, the attacker shifted the focus from stealing the password to stealing the user session. This is how Adversary-in-the-Middle (AitM) attacks appeared.
AitM techniques are based on the use of proxy tools standing between the victim and the login portal (for example, an SSO portal: Okta, Google Workspace, etc.). That is, the user sees the real login page, but somewhere between the user and that page, the attacker gains control of the user's session. And you don't even need to steal the account password, because user sessions can remain active for more than a month.
The browser-in-the-middle technique is based on integrating the attacker's infrastructure into the connection between the victim's browser and the target web application. Once the victim clicks on the phishing link, the attacker will direct their browser to their platform, which will redirect all requests to the original web resource. And at the same time, intercept data in this connection.
The victim should not notice anything suspicious, because they are interacting with a legitimate site. Their browser displays the attacker's browser with the same content as usual. To do this, the villain needs to deploy a platform that consists of several components:
This kit allows the victim's browser to access a legitimate web application while still transmitting secrets to the attacker. Here is a set of utilities that will make BitM attacks easier for the Red Team:
Blue Team, get your detectors ready!
The Reverse Web Proxy technique is based on the use of tools that redirect HTTP requests from the victim's browser to the resource through the attacker's proxy server. Tools for implementation with similar capabilities:
Info
For more information on organizing phishing campaigns, read the article "Evilginx + Gophish. Raising the infrastructure for simulating phishing with 2FA bypass".
To protect against this technique, a web application developer with MFA should use additional measures. For example, add JS code to their application to check the legitimacy of the domain that loads the page.
The key difference between AitM and classic phishing is that the attacker does not need to create a fake login page that completely copies the original. In the case of AitM, the bad guy shows the victim the original page without any changes. Therefore, classic methods for detecting phishing kits will not help in this case.
The use of a reverse proxy between the user's browser and the MFA portal can be detected using a JS script embedded in the web page. This script can act as a canary and signal the owner of the MFA application and the Blue Team analyst about a phishing attempt:
Let's make a similar canary in CSS:
We add various CDNs to the white list of addresses and wait for signals.
I remember using fuzzy hashing algorithms to search for malicious code back in university, and recently I came across an article in which these same algorithms are still effectively used to protect against phishing. Briefly about the method: we create a hash value of an artifact (for example, a web page) and try to determine the degree of similarity with the hash of a malicious artifact. It's that simple, without AI. But it works.
The effectiveness of the method was proven using the example of well-known phishing kits and pages that have been noticed in popular targeted attacks. The researchers calculated a fuzzy hash (TLSH) for the DOM tree of the obtained web page, compared it with the hash of a previously noticed phishing page, and thus detected a threat.
If you are wondering how to further improve your method for finding threats and anomalies, then do not rush to attach AI. Many tasks are still handled by algorithms “before the era of ML”.
Source
The same scenario is typical for many targeted attacks. It still works in some places, but it is losing its effectiveness as awareness programs, email content filtering technologies, and multi-factor authentication (MFA) are implemented.
MFA does not allow an attacker to use a stolen account because a second factor is required to access the data, which remains with the employee. To bypass MFA, the attacker shifted the focus from stealing the password to stealing the user session. This is how Adversary-in-the-Middle (AitM) attacks appeared.
AitM techniques are based on the use of proxy tools standing between the victim and the login portal (for example, an SSO portal: Okta, Google Workspace, etc.). That is, the user sees the real login page, but somewhere between the user and that page, the attacker gains control of the user's session. And you don't even need to steal the account password, because user sessions can remain active for more than a month.
Someone's Browser in the Middle: BitM Phishing Tools
There are two main techniques for AitM phishing: Browser-in-the-Middle (BitM) and Reverse Web Proxy.The browser-in-the-middle technique is based on integrating the attacker's infrastructure into the connection between the victim's browser and the target web application. Once the victim clicks on the phishing link, the attacker will direct their browser to their platform, which will redirect all requests to the original web resource. And at the same time, intercept data in this connection.
The victim should not notice anything suspicious, because they are interacting with a legitimate site. Their browser displays the attacker's browser with the same content as usual. To do this, the villain needs to deploy a platform that consists of several components:
- A customized browser with a minimal GUI so as not to distract the user with unusual interface elements. Chromium, deployed on the basis of a distribution with Fluxbox, is often used for this.
- A VNC server that provides access to the attacker's browser and is installed in his infrastructure.
- VNC client. For example, noVNC. Works in the context of the victim's browser and connects to the VNC server. The connection is made using a set of JS scripts and HTML5 code and does not require the installation of additional modules.
This kit allows the victim's browser to access a legitimate web application while still transmitting secrets to the attacker. Here is a set of utilities that will make BitM attacks easier for the Red Team:
- EvilnoVNC - using Docker allows you to quickly deploy all platform components for carrying out BitM attacks;
- CuddlePhish is a similar platform, but based on WebRTC technology.
Blue Team, get your detectors ready!
Bypass Multi-Factor Authentication with Reverse Web Proxy
The limitations of BitM attacks do not allow this technique to be used for mass phishing. When content is displayed in a browser via remote access protocols, the user only needs to resize the browser window to notice something suspicious in the page display. Also, Blue Team may have noVNC script detections in the corporate network. Therefore, BitM is well suited for targeted attacks, but is not suitable for widespread use.The Reverse Web Proxy technique is based on the use of tools that redirect HTTP requests from the victim's browser to the resource through the attacker's proxy server. Tools for implementation with similar capabilities:
- Evilginx is probably the most popular framework written in Go. It spins up its own HTTP and DNS server to intercept accounts and user sessions to bypass MFA.
- Modlishka is a similar tool, the developer of which describes its solution as “point-and-click”, meaning it’s easy to set up and automate.
- Muraena.
- CredSniper.
Info
For more information on organizing phishing campaigns, read the article "Evilginx + Gophish. Raising the infrastructure for simulating phishing with 2FA bypass".
To protect against this technique, a web application developer with MFA should use additional measures. For example, add JS code to their application to check the legitimacy of the domain that loads the page.
How to protect yourself: setting traps with JS and CSS canaries
In the basic reverse proxy phishing attack scenario, the attacker does the following:- Registers a domain name similar to the domain name of the target web portal that the victim uses to log in.
- Places a proxy on the phishing domain and redirects all requests from the user's browser to the target resource and back from its domain.
- Intercepts the entire authentication process and extracts valuable data from HTTP requests: passwords and session cookies.
- Uses intercepted session cookies to bypass multi-factor authentication.
The key difference between AitM and classic phishing is that the attacker does not need to create a fake login page that completely copies the original. In the case of AitM, the bad guy shows the victim the original page without any changes. Therefore, classic methods for detecting phishing kits will not help in this case.
The use of a reverse proxy between the user's browser and the MFA portal can be detected using a JS script embedded in the web page. This script can act as a canary and signal the owner of the MFA application and the Blue Team analyst about a phishing attempt:
- The victim opens the phishing link, and a JS script is executed in the browser.
- The script determines the context in which it is executed (e.g. URL) and matches the actual domain name with the expected one.
- If the context does not match, the script sends a signal to the Blue Team server.
Let's make a similar canary in CSS:
- For an image invisible to the eye (pixel), we create a url() attribute that sends a request to the Blue Team server.
- The Referer value is passed in the HTTP request header.
- If the Referer value does not match what we set, we send a signal to the Blue Team analyst.
We add various CDNs to the white list of addresses and wait for signals.
Detecting Phishing Resources with Fuzzy Hashing
The development of phishing attack tools leads to an increase in the number of resources that hook user and corporate credentials. At the same time, there are many effective methods for detecting these tools (phishing kits): from analyzing the structure of web pages to using deep learning algorithms.I remember using fuzzy hashing algorithms to search for malicious code back in university, and recently I came across an article in which these same algorithms are still effectively used to protect against phishing. Briefly about the method: we create a hash value of an artifact (for example, a web page) and try to determine the degree of similarity with the hash of a malicious artifact. It's that simple, without AI. But it works.
The effectiveness of the method was proven using the example of well-known phishing kits and pages that have been noticed in popular targeted attacks. The researchers calculated a fuzzy hash (TLSH) for the DOM tree of the obtained web page, compared it with the hash of a previously noticed phishing page, and thus detected a threat.
If you are wondering how to further improve your method for finding threats and anomalies, then do not rush to attach AI. Many tasks are still handled by algorithms “before the era of ML”.
Source
