Skip to content

Creating Server Content

Spencer McIntyre edited this page Apr 9, 2019 · 17 revisions

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

File Permissions

The King Phisher server user (either root or the user specified in the server configuration's 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

When creating a new landing page, the King Phisher javascript resource /kp.js should be included in the html head tags. This resource is used to facilitate injecting dynamic javascript (such as BeEF hooks) into pages that are served to victims. This resource can be included with a simple script tag such as <script src="/kp.js" type="text/javascript"></script>. In the case of landing pages created using King Phisher's integrated page cloning functionality, the /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>

Parameter Aliases

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
password password, pass, p
username username, user, u, login
mfa-token mfa, mfa-token, otp, otp-token, token

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 the request.credentials.regex_validated template variable. The template variable will have one of the following three values depending on the validation results:

  • 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

Server pages can also host any javascript including BeEF hooks which can facilitate launching browser based exploits. While javascript can be placed directly in any HTML content in the web root, a BeEF hook URL can be set through the client's GUI configuration dialog. By setting the BeEF hook through the King Phisher configuration, clients will load the hook on all pages which load the King Phisher javascript resource.

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 the template.

For example, with VHOSTS disabled and a web root directory of /var/www, the directory tree may look like:

  • /var/www/.metadata.yml
  • /var/www/training.html
  • /var/www/email/.metadata.yml
  • /var/www/email/login.html
  • /var/www/email/logo.png
  • /var/www/email/welcome.html

In the example directory tree, two templates are available, one single page template (trainging.html) in the web root, and a more complicated multi-page template in 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 selected.

Template Metadata Schema

The metadata file contains various keys with their associated values in the YAML format.

Key Type Value
authors [String] A list containing each of the author names.
classifiers [String] A list of string classifiers for describing functionality.
description String A text description for the template, containing any notes for the user.
homepage String A URL for the homepage where the template originated.
pages [String] A list of relative paths suitable for use as landing pages.
title String The template's title.
version String The version of the template data.

Page Paths

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 be updated.

The pages for the example email site template would look like:

pages:
  - login.html
  - welcome.html
You can’t perform that action at this time.