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.
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.
Pictures tell a thousand words…
the mailer is started in gui mode. it can also be run as a service (using nssm)
You can find the source for Pond on GitHub.
Pond now features an API, and the source code has been released – as detailed in the post: Revisiting the Watering Hole – Again.