Creating Server Content
The King Phisher server hosts HTML content from the directory configured as the web_root. It tracks users and associates them with campaigns by monitoring request parameters and using cookies.
Dynamic content is supported through the powerful Jinja2 template engine. For more information on writing dynamic HTML pages for use with King Phisher, see the Templates wiki page.
Configuring The Web Root
The King Phisher server setting
require_id can be configured to true to only
serve pages when a resource is requested with a uid that can be associated with
a campaign. This helps to prevent undesired attention to the landing pages. With
require_id setting enabled, users will not be able to directly visit a
landing or view site content without first getting a valid uid (for example by
clicking a link from a sent email).
Additionally the server setting
vhost_directories can be enabled to divide the
web root into sub-directories based on the requested VHOST. This is useful when
multiple DNS entries are pointing to the same server. For example if a request
is received with a VHOST of "example.com" and the
web_root setting is
configured to "/var/www" then "/var/www/example.com" will be used as the web
root for the request.
The King Phisher server user (either
root or the user specified in the server
server.setuid_username field) must be able to read the files
in the webroot. Typically, on Linux new files are readable by the everyone group
and by extension the King Phisher server user, however to explicitly provide
permission to the King Phisher server user, it's recommended to create a group.
The King Phisher server user and regular users should be members of this group.
In a multi user environment, the
setgid bit can be used in conjunction with
setting the owner of the webroot to the King Phisher group. This will ensure
that new directories in the webroot are owned by the King Phisher group and that
the members of the group retain access to make changes.
Configuring Landing Pages
Landing pages are HTML pages which are presented to users when they are enticed to click a link from a message. The content of these pages can be anything from informing the user of the phishing attempt and educating them to presenting the user with a fake login page in an attempt to harvest credentials.
The King Phisher Templates repo contains a variety of example landing pages. The examples are a good place to get started with seeing how content should be created.
Adding The King Phisher JS Hook
should be included in the html head tags. This resource is used to facilitate
victims. This resource can be included with a simple script tag such as
pages created using King Phisher's integrated page cloning
/kp.js script will automatically be spliced into the
resulting HTML. The
kp.js file does not exist on disk and is a special
resource generated by the server from a template file.
Pages For Harvesting Credentials
King Phisher can be used to harvest credentials as part of a social engineering attack when a user visits the page. The login page needs to be written in such a way that a "username" and a "password" parameter are sent to any resource on the King Phisher server via either a GET or POST request. The server will then record the values of these parameters in the campaign database.
Example HTML form for credential harvesting:
<form method="post" autocomplete="off"> <h2>Please Sign-in</h2> <input name="username" placeholder="User" autofocus /><br /> <input name="password" type="password" placeholder="Password" /><br /> <br /> <button type="submit">Sign in</button> </form>
The King Phisher server is lenient regarding the naming of the credential parameters. The following table outlines the various possible aliases. In addition to the other possible names that parameters can use, they can be in any configuration of lowercase uppercase or title-case.
|Parameter Name||Other Possible Names|
Pages For Not Logging Passwords
Sometimes it's desirable to only know what users submitted their credentials and not actually log and store them on the King Phisher server. HTML forms for logging credentials can easily be converted to drop the password from the HTTP request so it is never sent to the King Phisher. In this configuration the server is only sent the username and not the password. A blank password will show up in the logs and database of the server.
To do this simply remove the
name field from the password input and add an
additional hidden input field named password with a blank value. A password
field will still be shown to the user however it will not send it's value to the
server due to it not being named. Both a username and password must be sent to
the server, and using this technique a blank password will always be sent to the
server from the hidden input field.
Example HTML form for logging only usernames who submit credentials:
<form method="post" autocomplete="off"> <h2>Please Sign-in</h2> <input name="username" placeholder="User" autofocus /><br /> <input type="password" placeholder="Password" /><br /> <input type="hidden" name="password" value="" /><br /> <button type="submit">Sign in</button> </form>
Validating Submitted Credentials
Each field of a credential set (username, password, mfa-token) can be validated
using a regular expression configured on a per-campaign basis. The results of
which are available both in the Credentials tab of the GUI as well as through
request.credentials.regex_validated template variable. The template
variable will have one of the following three values depending on the validation
None– No validation took place on the credential set. This would be because either there was nothing configured or the configuration was invalid (for example a regular expression was malformed).
True– Validation took place and all fields that were properly configured for validation were present and passed validation.
False– Validation took place and one or more fields were either missing for failed to pass the configured validation checks.
These values can then be used in conditional statements to check the results of validation, for example:
regex_validated is eq(true)– True if validation took place and passed.
regex_validated is not eq(false)– True if validation did not fail (either validation passed or no validation took place).
regex_validated is none– True if no validation took place.
Pages For Exploitation
Pages For Training
Sometimes it is desirable to present the user visiting a landing page with
training material to inform them regarding the mistake that they made. During
these types of campaigns, King Phisher users can prompt phishing targets to
acknowledge that they have read and understand the training materials. This
acknowledgment is then presented in the King Phisher client under the "Trained"
column in the
View Campaign > Messages tab.
In order for this field to be set, the visitor needs to have a HTML form which makes a request to any resource on the King Phisher server with the query parameter "trained" set to "true".
Example HTML form for acknowledging training:
<form method="post"> <p style="text-align: center;"> <em>Please click "I Agree" to acknowledge this training.</em> <input type="hidden" name="trained" value="true"> <input id="trained-input" type="submit" value="I Agree" /> </p> </form>
Defining Template Metadata
New in version 1.13.0.
Template authors can define metadata for their site to help users understand
what the template does and how to use it. Metadata for a site template is
defined in a
.metadata.yml file which is then placed in the root directory of
For example, with VHOSTS disabled and a web root directory of
directory tree may look like:
In the example directory tree, two templates are available, one single page
trainging.html) in the web root, and a more complicated multi-page
email/. Each of these need a
.metadata.yml file to be defined to
provide the necessary information to the client so their content may be
Template Metadata Schema
The metadata file contains various keys with their associated values in the YAML format.
||[String]||A list containing each of the author names.|
||[String]||A list of string classifiers for describing functionality.|
||String||A text description for the template, containing any notes for the user.|
||String||A URL for the homepage where the template originated.|
||[String]||A list of relative paths suitable for use as landing pages.|
||String||The template's title.|
||String||The version of the template data.|
Pages defined in the metadata will be used by the client to suggest URLs for
landing pages. These pages should be defined as paths, relative to the location
of the metadata file. This is to permit an entire template directory (such as
email/ in the above example) to be relocated without the metadata needing to
The pages for the example email site template would look like:
pages: - login.html - welcome.html