Recipe for a successful phishing campaign (part 1/2)
By: Security Shenanigans
Tags: Infosec, Security, Red Team, Pentesting, DevOps

Link to part 2: https://medium.com/bugbountywriteup/recipe-for-a-successful-phishing-campaign-part-2–2–68552806dcba

Introduction

Phishing attacks are great first-entry vectors with technical details which are frequently overlooked by both white and blackhat hackers.

Having participated in multiple phishing campaigns over the years, both in offensive as well as defensive teams, I’ve learned from trial and error a lot of these things to pay attention to. This article will try to summarize them.

Technical subjects

Even if phishing campaigns are often associated with Social Engineering, they have technical components which you need to be aware of in order to be successful. Some of the topics we will cover (superficially) are:

Difference between common phishing and spear phishing

SPF, DKIM and DMARC

OSINT

SSL/TLS

Spam filters

DNS and MX/SPF/DKIM (txt) records specifically

Homograph attacks

Considerations

I know a big percentage of the readers just go through the first lines of an article, so let me give you the best advice I can give you now. The first thing that you need to understand is that a phishing attack doesn’t necessarily have to start with an email. Yes, we will cover mostly phishing attacks through email in this story, but there are multiple ways in which you could arrive to a phishing site.

Also, not every phishing site is looking for your credentials or your credit card, or for you to download a malicious file. I’ve heard a lot of people say that as long as you don’t download any file, and you don’t input your credentials / credit card details anywhere, you could go around clicking everything you get sent. This is not true.

I’ve participated on multiple assessments where our entry point was someone clicking on a URL they shouldn’t have, and running a script through an XSS.

Or maybe they want you to send a request and perform an action on your behalf, exploiting a CSRF attack.

Or maybe they just want to exploit your outdated browser with something like metasploit’s browser autopwn (https://blog.rapid7.com/2015/07/15/the-new-metasploit-browser-autopwn-strikes-faster-and-smarter-part-1/).

Maybe they want to beef hook you (https://beefproject.com/).

Maybe the link doesn’t even have a URL but rather a UNC and someone inside your network is trying to relay your credentials (https://github.com/lgandx/Responder-Windows).

Maybe it’s one of the multiple relay attacks that have recently showed up on remote conference software due to the quarantine, in both zoom (https://thehackernews.com/2020/04/zoom-windows-password.html) and team viewer (https://thehackernews.com/2020/08/teamviewer-password-hacking.html)

I could go on, but I’ll stop and hope I’ve given you enough examples to prove the point.

Defining type and scope

One of the first things you need to define with your client is the scope of the campaign. Will this target all of the companies employees or will it target just critical highly privileged employees? In the latter, you’ll want to put together custom emails for each user, using interesting topics that are sure to engage them. This is called spear phishing.

Also, do you want to be able to use the credentials you’ve gathered from your campaign to start a pentest? This is a sensible approach and each company has different privacy policies. If you just want to asses your employees security level, you don’t really need to log every credential. You can just obfuscate a portion of the credentials before saving them and pull statistics.

You need to pre-define your metrics too. Of course you want to know what percentage of users clicked on the link. But you could also log how many times it has clicked the link. How many credentials they’ve tried. Have they tried to reset their password after receiving your mail? How long after receiving the mail? This is all interesting data you should be collecting for your employer.

Setting up the infrastructure

To start our assessment we are going to need information about our target. I’m not gonna go into the OSINT process here, since it is a really broad topic and I’m planning on writing another article about this. But lets just assume you’ve gathered the following information:

Email addresses of your targets General useful info of your recipients, such as time-zone and language (and specific interests if you’re spear phishing)

Now that you have this information, you’re going to need your own smtp server to send the email.

I don’t care how easy Thor makes it look. There are actual time requirements when setting up the required infrastructure, you can’t just send the email from anywhere.

You’re going to need

A publicly accessible server. You can use any of the cheap providers such as Linode, Digital Ocean, AWS, GCM, etc… (I didn’t name Azure since this tutorial is directed towards the Linux audience). They offer vps as cheap as 5 U$D per month. You don’t need a lot of resources, the cheapest option with 1gb of ram will usually suffice. In our case we used Digital Ocean. A domain name for your server.

I wouldn’t be thorough if I didn’t talk about homograph attacks here. They are basically variations of regular letters which look similar to the original letters. Think the Cyrillic Ғ instead of the regular F. This allows you to reserve a domain name similar to the one you want to spoof. I’m not actually a fan of this approach. In my experience, users are more trustful of other variables such as the green padlock in a URL than of the actual name. Besides, using these types of char sets can actually alert automated filters about your malicious activity. Do you really think Facebook hasn’t thought of a bot scanning the internet for new Faceboӧk.com domains? I much rather send a mail from notifications@facenotifier.com. We’ll use godaddy in this tutorial. A website to receive your users when they click the link (we’ll talk more about how to set this up later).

One consideration that you need to have is that most cloud providers block outbound connections to port 25/tcp (smtp) due to frequent spamming. This means that you’re going to have to contact them to lift this restriction before you can send any email (we had to create a ticket with Digital Ocean’s support).