Getting Started

How it Works

Email Phishing in it's simplest form consists of three (3) primary components.

  • Sending Emails
  • Hosting Websites
  • Tracking Analytics

There obviously are more complex forms of email phishing that include additional components, but for the sake of our conversation we are going to break it up to this simple structure.

Briefly we will discuss how Phishing Frenzy (PF) handles each one of these components at a high level.

Sending Emails

PF leverages rails' built-in convention for sending emails from within the application. This library is called Action Mailer and is very well documented on the ruby on rails website.

Action Mailer is very powerful and allows us to send emails in both an HTML or TEXT format based on your needs. The library also supports the ability to embed images inline, or even attach email file attachments among other nifty features.

PF leverages both Sidekiq and Redis as a queue management system for sending emails in the background and handling large batches. These technologies are the default settings within PF, but can be changed to foreground within Global Settings menu.

Hosting Websites

PF leverages Apache's web server technology on the back end to host phishing sites. When you configure a campaign within PF and make it active, you are essentially configurating a VirtualHost within Apache to run your website.

When a campaign is active that means Apache has deployed the website and placed the appropriate configuration file at /etc/apache2/sites-enabled/:id.conf. Once you make the campaign inactive, the configuration file is removed from the sites-enabled directory to no longer have the phishing site accessible.

If you ever need to deviate from the website defaults you always have the power to edit your VHOST configuration files on the back end to meet your needs.

Tracking Analytics

PF leverages tags within the phishing sites to track user clicks and other important analytics. Each PHP phishing page is deployed with a tag that will invoke when the page is loaded. The code that is run will make an HTTP POST request back to the PF application.

The PF application has an API that is listening for these POST requests when the appropriate paramaters are sent. Paramters such as UID, browser, IP, username, password, etc. are sent back to the server where they are then correlated to the appropriate campaign and stored within the database for reporting.

New Templates

When creating a new template for PF make sure to keep in mind that you’ll want to run your websites with a .php extension. You don’t actually have to write your websites using PHP, but PF will need to add specific PHP tags to your phishing website once they are deployed and active. This is required to ensure that each visitor is logged and tracked within the database. PF does this by using the UID parameter that is passed in from the phishing email to look up the target and log the results for your campaign.

Phishing templates leverage uploaded files which are assigned a specific function of email, website, embeded image attachment or a file attachment to the email itself. Image attachments are typically images you want to embed within the email. File attachments are files you can attach to your phishing emails.

Email files that are uploaded to a specific template should be named *.html.erb. This is so rails knows to send the email in HTML and the ERB tells rails to render the file as an embedded ruby block. This allows us to add ruby snippets within the email and leverage rails helpers when sending emails

Website files are used to host the phishing website with PF. These files are uploaded to the filesystem of the PF box. Once a campaign goes active these website files are used to deployed instance of the phishing website. By default PF will deploy the website to phishing-frenzy/public/deployed/campaigns/:campaign_id and configure /etc/apache2/httpd.conf to serve up the phishing website.

Once a file has been uploaded and assigned a function you can edit that file within the PF interface as long as it is an ASCII style format such as HTML, PHP, ERB or others.

If you are editing template files for an already deployed campaign these changes will not show up right away. You will need to make the campaign inactive first within the campaign options, and then re-activate the campaign. This will grab the most recent template files and deploy your recent changes.

Backup / Restore Templates

Once a template is created and working the way you like it can then be exported and backed up by PF to share with another PF instance or any other person in the community running PF. When you click the “backup” button within PF, all of the template files are archived into a zip file along with a couple YML files. These YML files specify the function for each file and are required to import back into PF properly.

Restoring a template into your PF is easy and all done through the web interface. Simply click the “restore” button within the templates section and select your zip archive to restore back into PF. Ensure the zip archive was properly exported from a PF instance or it may not restore properly into PF.

Phishing Emails

PF now sends email using Rails conventional method by using Action Mailers. By converting over to rails mailers PF gains a lot of benefits when sending emails. Some of these benefits include the ability to create and manage phishing templates more effortlessly.

PF templates are now a breeze and simply require some crafty HTML without having to worry about SMTP header nonsense. The rails mailer now handles all of that. We can now simply focus on creating HTML emails that look more enticing then ever. Also attaching images inline within the body of an email is simply done by leveraging rails helpers.

Since PF is using rails mailers we are able to create dynamic emails. What does that actually mean? That means we have the power of ruby within our emails! Say what? We can now code ruby snippets wherever we want within the email.

For example, you could use <%= @target.firstname %> to display the targets firstname if you imported a CSV list firstname content.

Here is a list of the 4 most common ERB tags that will most likely be used for your template creation. These tags allow you to display the firstname, lastname, and email address within the phishing email. The @url tag is used to display the phishing link within the email.

<%= @target.firstname %>
<%= @target.lastname %>
<%= @target.email_address %>
<%= @url %>

In order to track if a user has opened the email you will need to load a remove 1x1 pixel from the PF server. We add the following html to every email where you want to track if a user has opened the email.

<img src="<%= @image_url %>" alt="" />

Here is an example of how to use the ERB tags to create a simple phishing email. This email will display an attachment image inline (pizza.jpg). Also the email will greet the target by their firstname and create a phishing url using the @url instance variable.

<%= image_tag attachments['pizza.jpg'].url %>
Grand Opening - 309 Pizza!<br>
Hello <%= @target.firstname %>
We are pleased to be opening a pizza place in the Normal Illinois area.
We are offering some special deals for the grand opening through this week.
If you download our app/sign up on our website, you could win a free pizza.
Sign up on our website <a href="<%= @url %>">here</a><br>
So take a second and order an authentic italian pizza and taste the quality.
All of our pizzas are cooked in a wood fired oven with only the freshest ingredients and made to order.<br>

Vincent Walker<br>
<img src="<%= @image_url %>" alt="" />

For additional information on leveraging ERB please see the following documentation:

Phishing Websites

When hosting your phishing websites with PF the application will automatically add some PHP code to each .php once the campaign is active. This PHP code oftened refered to as tags helps take care of tedious tasks such as tracking user clicks, or tracking user credentials being entered into the site.

Additionally, these tags are now configured to return a 404 error if the URL does not contain the UID parameter. For example the url of will return a 404 because it does not contain a UID. If you are trying to test out your phishing site, ensure you add the required UID paramter as follows: The UID paramter does not need to exist in the database, the paramter just needs to be present within the URL to render the phishing site properly.

For more specifics of the actual PHP tags in use, please see: tags.txt.erb

Importing Targets

PF allows you to copy and paste your targets in a CSV format. The format can be entered in 3 different formats and each of them will work differently so ensure you fully understand how to import targets.

If you want to import a bunch of email addresses you can do this by simply adding a list without any commas. Here is an example of the format for adding 5 email addresses to a campaign.

If you wanted to import a list with an email address and the firstname, you would use the following CSV format: firstname, email. Here is an example of the format for adding 5 email addresses with a firstname tied to each email to be used within the phishing email.


If you wanted to import a list with an email address, firstname, and lastname, you would use the following CSV format: “firstname, lastname, email”. Here is an example of the format for adding 5 email addresses with a firstname and lastname tied to each email to be used in the phishing email.

firstname0, lastname0,
firstname1, lastname1,
firstname2, lastname2,
firstname3, lastname3,
firstname4, lastname4,

Once you’ve imported a list of targets you can double check to ensure they have been imported properly by clicking the targets number inside campaign options. This will show a table of all targets that are waiting to be sent to if and when you decide to launch the campaign.

Launching a Campaign

When you launch a campaign there are a lot of moving parts that occur on the back-end. The first is that PF will ensure that the phishing website is live, and if not it will make your phishing campaign active. This will make the phishing website live by configuring Apache’s virtualhost’s with the /etc/apache/httpd.conf file and restart the service (make sure www-data has sudo abilities to restart the service).

www-data ALL=(ALL) NOPASSWD: /etc/init.d/apache2 reload

Once a campaign goes active template website files are used to deploy an instance of the phishing website. By default PF will deploy the website to phishing-frenzy/public/deployed/campaigns/:campaign_id.

Sending emails in a phased approach

PF does not require you to send all the emails at one time. For example, lets say you wanted to send 100 phishing emails today, and then tomorrow you wanted to send out 300 more. This is totally possible, and easily obtainable with PF.

Enter in your 100 targets like you normally would into a campaign. Click the launch button like you normally would so the first 100 emails are sent out. PF is now aware of each target that was sent to and keeps track of their statistics throughout the entire campaign, even if that email is removed from the campaign.

Now on day two of the phishing exercise and your ready to send out 300 more emails. Simply go into the campaign options and click the target number. This will go to the page of all the targets listed in the campaign and click “Delete all” button. Since PF is already aware that these 100 targets have been sent to already, it will retain the stats and allow you to enter a new 300 email addresses. Once the new email addresses are entered into PF, simply click the launch button again and sit back and watch the stats generate.


Reports and statistics are generated on a campaign-by-campaign basis. Each phishing campaign will have its own set of statistics that are independent of any other phishing campaign.

The standard metrics that are tracked by PF are whether a user opened the email, clicked on the phishing link within the email, or entered credentials into the phishing website.

PF is able to determine if a user opened the email by embedding a 1x1 pixel into the email. This 1x1 pixel is hosted on the PF box so when a request is made for it the UID will be tracked. Some email clients will block the 1x1 pixel so this metric isn't always 100% accurate.

Global Settings

There are various settings that you can configure within the admin section of PF. Different operating systems may require different settings in order to run properly. For example, the default value for reloading apache is “sudo /etc/init.d/apache2 reload” however you may be running PF on a different flavor of linux that reloads apache with a different syntax. This is all configurable within the Global Settings page within the Admin of PF.

Stats aren’t tracking Visitors

PF will only track stats that have a UID parameter passed to it. For example, if you had a phishing website running as and simply visited it by clicking on the link, nothing would be tracked as far as PF is concerned. Sure the log would be recorded by apache, but the PF interface will not recognize it as a valid “click” and will not update the stats page or log this event in the database.

In order for PF to log the “click” within the database and tie it back to a phishing campaign, the UID parameter needs to be passed to the phishing site. For example the link of would pass the parameter of 00000000 to the phishing page. Typically the UID will be different than 00000000 but for demonstration purposes this UID would tie back to a specific target that is part of a specific phishing campaign. This is how PF is able to keep track of each visitor that clicked on the link. You don’t have to worry about generating a UID for each target or changing anything in the phishing email. PF takes care of all this automatically.

The stats rely on a critical configuration that you must ensure you setup correctly. This is the SITE_URL that is contained within the config/application.rb file inside your PF application. You must configure http://localhost to your FQDN of the PF interface. This is most likely the same FQDN you configured within /etc/apache2/pf.conf.

This SITE_URL variable is used each time a visitor lands on a phishing website. It calls back to this SITE_URL passing some of the visitors parameters and logs the details to the database. If your SITE_URL is not configured properly, you’ll never track stats for your phishing campaign.

Password Storage options

Phishing Frenzy offers the ability to not store the passwords which are harvested within a phishing campaign. Often times blue teamers want to assess the behaviour of end users but do not want to expose the passwords to the Phishing Frenzy application.

We have addressed this by adding both client-side and server-side code to ensure that passwords are not stored in cleartext when the campaign phishing option "Password Storage?" is not checked.

When the campaign is activated, JavaScript is added to the phishing site and instantiates an event listener on the "PasswordForm" input which is where passwords will be entered. The JavaScript will replace the real password credentials with meta-password characters.

For example, the character "a" would convert to an "l" for lowercase, "A" would convert to "L" for uppercase. Numbers and special characters are also converted in realtime to "n" and "s" respectively.

In the rare cases where JavaScript is not enabled in the browser, we have also added server-side code which will detect if the password has been properly converted to a meta-password. If the campaign determines that the real cleartext password has been sent by the browser, it will replace the password string with "MASKED" to never store the real password. All passwords harvested will still be accessible within the reports section of the application.