How Phishes Reach the Basket

My previous blog post highlighted both what a phishing kit is and what functionalities it usually provides to a fraudster who uses it throughout the duration of the social engineering attack known as phishing. I want now to focus my attention on the delivery methods used by this piece of software; that is, the way the information gathered from phished users is stored and ultimately delivered to the fraudster.
 
The evolution of the delivery methods is strictly related to the continued development of Web technologies. The first samples of phishing attacks we came in touch with years ago were entirely composed of static HTML-only pages. At that time, a server’s ability to host dynamic content was quite rare. Even then, any gathered credentials were usually sent to a vulnerable “Form to Email" program, which was a simple CGI script used to grab the parameters sent via a Web form and deliver them through an email message to a specified recipient.
 
As the number of Web servers able to host dynamic content grew and unrestricted access to Form to Email programs faded away, the way a phishing kit was built changed as well. PHP-enabled Web servers played a central role in this change. By way of dynamic languages, fraudsters were able to develop powerful and sophisticated kits, even embedding advanced countermeasures to protect their business from online antifraud service providers, as has been highlighted by Antonio Forzieri in this article.
 
In phishing kits built using dynamic languages, the information collected from the phished users is either written on text files residing on the server hosting the clone website, or can be sent by email. However, in the case of emailing the collected information, the local PHP mail engine was used without relying on an external “service” as was described in the previous scenario.

Nowadays, sending the collected credentials by email is still the leading delivery method. In some circumstances, plain text files are used too; however, the risk is that other entities such as concurrent fraudsters or the target financial institution itself could gain access to this data—a risk that is presumably considered to be too high. Even some old-style attacks employing vulnerable Form to Email programs to deliver the collected credentials are still around.
 
The table below summarizes the most relevant advantages and concerns a fraudster will face when going for a delivery method:

While Form to E-mail CGI programs are disappearing, some of the vulnerabilities affecting various Web applications could be exploited to achieve the same results. Although these security issues are not being exploited in the wild yet, I'm guessing it could start happening very soon. Web developers are strongly encouraged to follow common security principles to avoid introducing vulnerabilities to their applications, which could help fraudsters continue their attacks.