Phishing with Smitty: A Unique Tool for Solicitation Attacks

Phishing with Smitty: A Unique Tool for Solicitation Attacks

This post will introduce you to the Smitty SMTP utility, which is a fully featured email client. We use this tool as a means to effectively deliver email messages during solicitation attacks (e.g., phishing and phone pretexting) as it provides unique features that make it discernibly different from other available email clients. Smitty was originally developed by my former colleague, Tom Steele, in conjunction with my code contributions. The latter code pushes were implemented in order to address a specific spam filter bypass constraint.


The spam problem was one issue we were able to overcome by using Smitty, but the other issue was effectively performing click-through tracking on large phishing engagements. Once again, Smitty allows us to overcome this challenge using a very pragmatic approach.


What is Smitty? How do I get it?


Easy enough; just visit and follow the install instructions. The simplest method is to perform a “gem install smitty” from within a shell, since it is an official Ruby gem package. 


The following illustration provides the detailed command line options with a brief explanation of their usage:


Smitty 1


All of these options are self-explanatory with the exception of the following two:


  • messageid
  • vars


Coincidentally, these are the two items that I set out to explain in this post, as the “messageid” option provides a solution to one particular spam test case, and the “vars” option introduces greater flexibility when crafting our html email messages.


The “messageid” Command Line Option


The following reference from RFC 822 provides a description of the intent associated with the “Message ID” header as it applies to an email message.




This field contains a unique identifier (the local-part address unit) which refers to THIS version of THIS message. The uniqueness of the message identifier is guaranteed by the host which generates it. This identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message should each receive new message identifiers.


The ‘TL;DR’ version of this is that the “message id” header must provide a unique identifier for each message. The construction of the header, under normal circumstances, should be similar to the following:


An RFC-Compliant Message ID Value


Snitty 1.1


Notice that the Message ID header is comprised of two parts if we split on the “@” character. The left-most value is a unique value while the right most value is either a local system identifier or the sending domain.


A Non-Compliant RFC Message ID Value


So now what happens if we have a value that gets passed into the Message ID? For instance, mail clients that can’t handle a sender alias format such as “Chris Patten <>” would be parsed incorrectly and appear as the following:


Smitty 2.1


What just happened? Specifically, I leverage Google MX servers for my domain. When the Google mail servers identified a broken right-most value in the Message ID header, it tried to compensate by performing a fix. The value “SMTPIN ADDED BROKEN” is often caught by spam filters and, as a result, makes its way into the quarantine area.


Another Observed Problem


Certain email clients pre-populate their own values within the Message ID header. For instance, let’s take a look at the sendEmail utility and its respective header value.


Smitty 3


Notice that the Message ID header now contains the “sendEmail” value and a new “User agent” header that we have to contend with. Once again, a spam filter will detect these values and send to the quarantine bucket.


A Solution to Both Problems


I created the “messageid” option in Smitty to correctly account for parsing and populating the right-most value of the Message ID header. Furthermore, it allows for sender alias format, such as the aforementioned “Chris Patten” composition.


Finally, I wanted the ability to set my own domain in the event that I wanted to override the automatic parsing and pre-population of the domain value. The overall intent with Smitty was to provide security professionals with the flexibility of using an email client that is more aligned with performing phishing and spam evasion, rather than a simple command line mailer. This segues nicely into the next topic - the “vars” command line option.


The “vars” Command Line Option


I had been talking in the past with some of my colleagues while dealing with a rather sizable phishing engagement - more from the perspective of keeping multiple scenarios and geo-locales organized. I needed a method to track accountability regarding which region and who performed a click through. Essentially I needed a way to track who clicked a link within my email solicitation.


In order to address this issue, I leveraged the native handlebars support in the Smitty mail client. For those of you who aren’t familiar with handlebars, it is essentially a technique based off of mustache that can be used to bind data to an html element or attribute. Specifically, the “{{expression}}” syntax is used to bind data to document object model at the specified location, again the html element or attribute. Read up on it at Alright, so let’s see this in action and apply it to create our solution.


Create your html handlebars template with a name and extension like email.hbs. The “.hbs” extension is associated with handlebars templates, and in its simplest format looks something like the following:


Smitty 4


Now we need to create a few more files, the email_recipients_list.txt, the locales_list.txt (this will just help identify geographic region if necessary) and the uuids_list.txt (this will be used to track unique clicks initiated from email recipients). The important thing to note is that each list should have the same number of newline separated values. For example, if email_recipients_list.txt has 20 email addresses then the uuids_list.txt and locales_list.txt should have the same, since Smitty will iterate over the same file position in both lists. This is very similar to how the Pitchfork Burp Intruder payload works. Burp Pitchfork defines multiple positions and then associates a payload file. It then iterates through each payload file (value) and binds that to the define position (key) within the request.


So let’s say we have the email_recipients_list.txt defined with the following two entries:



Now onto the locales_list.txt file. Let’s say that the email address lives in Wales and the lives in Berlin. We would create a file with the following entries:


  • wales
  • berlin


Now we need to create the uuids_list.txt. However, it would be nice to not have to reference a real uuid and associate that back to an email address. A better solution would be to take something like the actual email address from the recipients list and encode it. Then pass that value in as the uuid. Then we can just decode the value and observe the original email address. I played around with a couple of encodings but decided on a simple hex representation because that didn’t look awkward within the URL. I am positive there are better obfuscation representations, but we will keep it simply for display reasons. Let’s drop into the Python CLI to do this right quick:


Smitty 5


Now we can add these into the uuids_list.txt file. Our file should have the following two entries:


  • 6370617474656e407061636b657472657365617263682e636f6d
  • 63687269732e70617474656e40666973686e657473656375726974792e636f6d


Now if we want to send our email using our previously defined email.hbs and bind our individual values within our email_recipients_list.txt and uuids_list.txt files, we just do the following:


ruby ./smitty --server --port 25 “Clown Phish <>”  email_recipients_list.txt “A message has been sent about scary clown!” --vars ‘locale=locales_list,uuid=uuids_list.txt’ email.hbs


Note: the important thing here is that in the “--var” command line flag we have a comma separated list containing a key value pair. Specifically, the key (I.e., locale or uuid) are actually defined within the handlebars syntax “{{ }}” of our email.hbs template, while the value (I.e., locales_list.txt or uuids_list.txt) is the object that will be iterated over. Each value (newline separated value) will then be inserted into each message at the key position allowing us to send unique emails to each of our intended recipients.


With all that said, we can take a look at the way the email is received and inspect the actual href value. It should be constructed as follows for the and emails, respectively:



After all is said and done, we can inspect our Apache2 access logs to capture the logged URL requests (i.e., click-through). How do we know who clicked our link though? Easy enough, once again let’s drop into python:


Smitty 6


There we go! Yes, we could wrap a bunch of programmatically nice syntactical shine to the process, but I hope this describes the problem and one solution to the problem.