Earlier this year, in May, I wrote about a phishing framework that I used to mount a company wide phishing campaign – for testing purposes, of course. Since then several other companies have used the application for the same purpose, and there has been some real interest in it within the local security community. This interest sparked a revival of the project: complete rearchitecture, redesign and rethinking of how it should be used. Whilst the code isn’t quite ready for public release and I haven’t started on documentation, in this post I’ll outline the new architecture and demonstrate a campaign from beginning to end.

 

architecture

Pond now requires Forms Authentication to log in to the adminsitration console. There is no authorisation model quite yet, as it’s assumed that only a single person will operate it or multiple people don’t care if they share the same account. Should interest be expressed in having one then the building blocks are there to implement it. Credentials are protected by scrypt – so rest assured that nobody will be breaking those any time soon.

Once in the administration console the changes become very apparent. The biggest change to Pond is the introduction of the concept of multiple, on-going campaigns. Each campaign is very configurable, allowing you to define:

  • Campaign name.
  • Landing page template.
  • Email template:
    • Email appearance with set ‘name’ and ‘URL’ variables.
    • Sender address.
    • Sender name.
    • Message subject.
  • Victim name and corresponding email addresses.

All of this is made very easy with an intuitive interface, WYSIWYG editors (TinyMCE) and real-time serverclient feedback via SignalR. SignalR also permits for multiple people to work on the same campaign, as if one saves a campaign then the changes can easily be propogated out to others. Another key requirement to allowing multiple campaigns is of course persistent storage: achieved using PostgreSQL. The database is fairly slim, having only 20 columns across 4 tables.

Being blacklisted as a spammer isn’t so much of a concern for me as I have a dedicated SMTP server at my disposal, however for those who use cloud providers it may prove an issue to be sending out hundreds of identical messages at once – therefore mail is now slightly more controlled. Instead of sending mail out of the application pool process it is sent to a Windows service via MSMQ. The service listens to a private transactional queue and sends off blocks of messages to an SMTP server as they arrive into the queue. Of course, if the SMTP server becomes unavailable then messages will simply be left in the queue until such time as it kicks back into life.

demonstration

Pictures tell a thousand words…


for the meanwhile, accounts are manually created in SQL


a user logs in


here, there are no current campaigns


so a campaign is started


selecting the campaign presents the editor controls


info: edit the campaign name, and view its status and time last altered


landing page: edit the appearance of the landing page victims will see


email: define the sender parameters, and edit the template of the email sent to victims. the ##NAME## variable will be substituted with the victim name in the sent email


an html editor gives great control over the apperance of landing pages and emails. the ##URL## variable will be substituted with the unqiue victim link in the sent email


victims: a csv list specifies the recipients of the campaign


actions: save the campaign, run it, reset the results or delete it.


the mailer is started in gui mode. it can also be run as a service (using nssm)


selecting ‘run’ saves the campaign and submits it to the msmq queue


the mailer receives the msmq messages, forms the unique email messages and fires them in batches to the SMTP server


a sample email with the victims name and a unique link

a sample landing page


this campaign only has two recipients. the graph illustrates this and detailed information on the hit is in the textarea below it


once underway, the status of a campaign becomes ‘submitted’


a ‘submitted’ campaign cannot be updated until it is reset


resetting a campaign removes all targets and results from the database


once a campaign completes it can be retained in ‘submitted’ state or deleted


a deleted campaign is immediately removed from the campaign list of all users

source

You can find the source for Pond on GitHub.

update

Pond now features an API, and the source code has been released – as detailed in the post: Revisiting the Watering Hole – Again.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s