-
Notifications
You must be signed in to change notification settings - Fork 531
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.
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.
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.
To set the webroot permissions (using "KP" as the King Phisher group and
/var/www as the webroot):
# Set the group to "KP"
chown :KP /var/www
# Set setgid bit and the permissions to allow the KP group read write and execute access
chmod 2775 /var/www
# Set the default directory permissions to be 775
setfacl -R -d -m u::rwx -m g::rwx -m o::r-x /var/www/
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.
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.
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 |
|---|---|
password |
password, pass, p
|
username |
username, user, u, login
|
mfa-token |
mfa, mfa-token, otp, otp-token, token
|
Instead of using form based authentication and collecting credentials that are
submitted, the King Phisher server can prompt for users to authenticate to it
using Basic access authentication. To do this, set the template variable
require_basic_auth to True. This will prompt visitors to this page to
authenticate to the King Phisher server, and the credentials will be stored in
the database in the same manner as if they had been submitted via the previously
described form-based authentication. See Requiring Basic Authentication for
more details.
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>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.
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.
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>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.
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. |
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