Social Engineering Stories: One Phish, Two Vish, and Tips for Stronger Defenses

October is Cybersecurity Awareness Month, serving as a crucial reminder of the importance of safeguarding our digital lives. This year’s theme is “Secure Our World” with an emphasis on recognizing phishing and vishing attempts – two prevalent tactics used by bad actors to exploit unsuspecting individuals. Understanding these risks is essential for companies, employees, and consumers alike, as they can lead to identity theft, financial loss, and even emotional distress.  

In this article, we will dive deep into the sea of phishing and vishing, sharing real-world stories and insights we’ve encountered during social engineering tests to highlight the importance of awareness. Read on as we uncover real tactics and discuss effective strategies to protect your company and its sensitive information in today’s digital landscape.

Email Phishing Using an Open SMTP Relay by Michael Jereza, Senior Security Consultant 

A customer engaged with us to perform phishing assessments on its subsidiary companies without providing any information on targets or email configurations.  

Initial Access Attempt 

After collecting a list of just under 1,000 potential emails and getting customer approval, our team attempted an initial phishing campaign. However, no emails were opened during this initial campaign. We suspected there was some sort of email filtering blocking external senders in place, which was the case for previous assessments of the customer’s other subsidiaries. 

Part of the requirements for a standard phishing test is allowlisting our sending domains. However, since this parent company does not manage the email filters for each subsidiary we could not proceed with the assessment. Even in the most perfect scenario, a phishing campaign will inevitably get blocked when you’re sending emails to 1,000 people. 

Exploitation 

Then, around midnight, one of the security experts performing the external penetration test on this subsidiary shared that he had found an open SMTP relay. 

After getting customer approval, we re-sent the email campaign through this relay. It made our phishing emails appear to come from the legitimate “@company.com” domain rather than our registered phishing domain @comprany.com.  

The following email was sent:

Each hyperlink was actually embedding the phishing domain “company.com”, but it appeared as the legitimate domain for anyone who didn’t hover over the links.  

Results 

• Several email links were clicked out of all emails sent
• People entered their credentials on a fake Microsoft SSO page, some did this multiple times 
• According to LinkedIn, the credentials belonged to many leadership positions

This ultimately resulted in a SOC incident for the subsidiary and the most successful email campaign we’ve performed for this customer. The scariest part is this unauthenticated email relay was easily accessible from the internet, and anyone could’ve successfully phished this company.

Social Engineering Prevention Tip

In-Depth Vishing Attempt by Dalin McClellan, Principal Security Consultant

To more accurately simulate a real-world attacker, a customer wanted to provide us with as little information as possible for a phone-based social engineering engagement. I was given the name of the company and a goal of targeting 30 employees using phone-based social engineering to gain as much access as possible, especially access to executive-level accounts. The customer didn’t provide any other information. 

Recon

Initial Open-Source Intelligence (OSINT) research turned up names and emails of about 2,000 individual employees across 10+ countries and five domains. A few clever Google dork searches also helped me discover their internal employee portal. The portal helpfully included an unauthenticated and non-rate-limited API which allowed me to quickly verify which email addresses I had were valid, and also told me which business branch the employee works in. 

I narrowed down my list of targets to 30 valid employees, ranging everywhere from low level admin assistants to C-suite executives. 

Next, I began exploring their phone system. I found that if you called their main corporate phone line after hours, they had a dial-by-name directory which disclosed the direct-dial phone number of the person whose name you entered. Two hours of manual, late-night calls later, and I had phone numbers for all of my targets. 

Initial Access

I began making phone calls to employees, telling them I was from their internal IT department, and doing some follow-up on old support tickets that never got closed. “Everything good on your end? No more issues getting on the VPN? Great, can I have you check one thing for me? Go to [example].com and enter your credentials.” 

Using that method, I got three people to enter their credentials on a custom phishing site right away. Unfortunately for me, they had MFA enabled on all of their accounts. I still couldn’t log in without that code!

Not one to easily get discouraged, I made another call. This time, as soon as the person entered their credentials in the phishing site, with them still on the phone, I quickly went to the legitimate employee portal and attempted to sign in as them. After entering their username and password, I asked if they had received an MFA code. They said they did, and (without even being asked) happily read it out to me over the phone. I entered the MFA code on my computer and was now signed in to their account.

Exploitation 

I now had internal access to their employee portal! I wanted to make sure I was able to get back into the account if I ever got signed out, so I added my own phone number as a secondary MFA provider. That way I could re-login to the account whenever I wanted and could receive the MFA code to my phone. Also, just for backup, (and to prove it wasn’t a fluke) I repeated the process a few more times, until I had full access to three different employee accounts, including an internal software developer.  

Time to start digging around! I quickly found that the employee portal linked to Citrix, giving me access to internal desktops with local admin permissions. For this engagement, a full internal penetration test/red-team style escalation was out of scope, but almost certainly possible. 

Continuing, I dug through documentation on their internal SharePoint and found an account with weak credentials and no MFA enabled. The account was intended to only be used internally for password resets and troubleshooting. However, Patrick Sayler discovered that this “internal only” account was able to sign-in externally, and could access their internal SharePoint site as well as Azure AD. This meant we had nearly unauthenticated access to all their internal documentation, as well as their entire internal employee directory. 

I sent a message to the customer letting them know about this gap. They shut that account down right away and gave us big kudos for finding it and bringing it to their attention, even though it wasn’t technically part of the test. 

Executive Escalation 

We took this test further and targeted executives. I registered a new domain similar to their legitimate employee login domain, then spun up an Evilginx server which proxied traffic to their legitimate employee login site and captured credentials entered, including MFA codes as well as session tokens.  

Next, I used one of my previously compromised accounts to access Microsoft Teams. With everything ready, I placed a call to one of their corporate executives. Claiming to be a software developer, I said that I was working on a new “exclusive to executives” authorization flow, but I need someone with that level of account to sign-in to it so we can “generate some logs we need on the back end.” 

At first, the executive was skeptical, but I used the compromised account to send a confirmation message through Microsoft Teams, along with a link to the phishing website. A few moments later, the executive entered their credentials into the phishing site, which were immediately captured and replayed, giving me access to the account.

Social Engineering Prevention Tip

Tips from The NetSPI Agents 

For security teams and leaders, it’s important to remember that social engineering is still the top method threat actors use to enter a company’s IT and security environment. Here are a few tips to ensure that your company and the people in it are resilient to these types of attacks. 

• Implement Strong Technical Controls: Establish robust security measures to mitigate. the impact of successful phishing attacks, including MFA to add an extra layer of security. 
• Streamline Reporting Processes: Create an easy, user-friendly system for employees to report suspicious activity and phishing attempts, minimizing reliance on traditional help desk procedures. 
• Run regular social engineering penetration tests. 

For more tips and a deeper dive into social engineering, check out our blog post: Ask These 10 Questions to Enhance Your Social Engineering Testing.