Case Study: Navigating the Murky Waters of Phishing

As one of the oldest tricks in the cybercriminal playbook, phishing remains a potent threat to all organisations. At OmniCyber Security, we are experts in cybercriminal behaviour and regularly use phishing in engagements with clients to test their cyber defences. This case study explores one such engagement, highlighting the vulnerabilities that phishing exploits, and shedding light on the importance of robust security measures.

Phishing’s appeal lies in its simplicity: a well-disguised email, a cleverly crafted website, and, within moments, a breach is underway. This case study immerses you in the complex world of phishing, unveiling the vulnerabilities it exploits and the broader cybersecurity landscape it navigates.

By dissecting the real-world phishing tactics from this recent engagement, this case study goes beyond the surface-level understanding of these attacks. It offers a comprehensive view of how organisations fall victim to phishing, from the initial lure to the costly aftermath. We will explore the various tactics employed by cybercriminals, the vulnerabilities they target, and the security lessons we can learn from their activities.

Phishing for Access

In this engagement, we began by targeting the organisation’s staff with phishing messages sent to their work mobile phones, using a list of mobile phone numbers and associated email accounts retrieved via OSINT. The messages contained a spoofed short code (e.g. COMPANY IT), the user’s correct email address, and a link to a domain under our control. This domain also contained a cloned Office 365 login page that looked identical to the real thing.

Six users inputted their credentials on this deceptive page, which were then captured by us and relayed to Microsoft, granting us access to their emails. Additionally, we discovered that some users were using vendor-provided or default credentials, making our task even easier. The pattern we identified was two question marks followed by the first three letters of the staff member’s surname (including a capital letter) and two more question marks. An unusual pattern, but still a pattern, which means we can exploit it.

With the credentials retrieved via SMS, we widened our phishing net. We pulled down a list of all users from Azure Active Directory (AAD) and created a large list of potential passwords, which we tested against the Office 365 infrastructure. This method yielded valid credentials for dozens more user accounts.

Trawling for Vulnerabilities

In the post-exploitation phase of an engagement, the consultant leverages the access they have achieved to find paths of privilege escalation. This often involves looking for internal resources that contain passwords or privileged information that could be used for further access into internal infrastructure and accounts.

With multiple valid credentials and levels of access via Email, Remote Desk Protocol (RDP), and SharePoint, we gained access to the company’s internal and cloud infrastructure. We observed multiple security vulnerabilities during this phase:

1. Passwords and Credentials: We noted passwords and credentials being sent via email or Teams, a practice that can easily be exploited.
2. Sensitive Credentials: Various credentials and passwords for resources were saved in SharePoint, a risky practice that we capitalised on.
3. Security Files: Large password files for multiple resources were saved on shared drives and desktops, presenting further security lapses.

These vulnerabilities allowed us to gain further access to Office 365 resources using the discovered credentials. We also observed internal communication practices for potential use in further exploitation, including spearphishing and whaling. We successfully connected to the company VPN, logged into multiple user’s desktops and resources via RDP, enumerated domain users’ roles and network privileges, identified all domain-connected resources, and discovered all users with domain admin rights. This extensive access allowed us to compromise accounts, files, purchase orders, and payroll.

To be clear, the above findings are something we see regularly during engagements for new clients, they’re not unique to this case study. SharePoint administration from a security perspective is complex and requires a careful balance of accessibility and security. Add in that phishing a highly privileged user might just make all the security and access roles redundant, and the stakes can be high in a genuine attack.

Whaling: A High-Stakes Game

The level of access gained at this point was significant, but with some time left in the engagement, we wanted to provide additional value in terms of results and learnings for the client. By using previously retrieved credentials, we enumerated both Active Directory (AD) and Azure Active Directory (AAD) (now called Microsoft ENTRA ID) and identified a suitable target. This user was in the Domain Administrators group for Active Directory but also had an external presence in the form of an email address. [This is not best practice, but again is something we see in less mature clients at the start of their cybersecurity journey.]

The only stumbling block at this point was: this user knew we were conducting this engagement – one of only two people within the organisation. We always try to keep the number of users aware of our tests as low as we can, to make the simulated attack as real as possible, but obviously, some people have to know what’s going on, and we have to work around that.

Around this time, another user’s inbox we had access to started to show Automatic Replies which suggested they were on annual leave for a few days. Using a member of finance/credit would increase the chance of response/success as their role was Key Account Project Manager. Additionally, the member of staff being on leave meant it would be unlikely that could check verbally with the member of staff and may also be hesitant to call them.

We crafted a phishing email tailored to a customer account that had been recently discussed in emails. This would ensure that the account was relevant and active. The phishing email contained a link to a fake Office 365 login page, disguised as a document:

This was initially met with some hesitation and/or suspicion:

Another email was sent after OmniCyber Security checked a few details regarding the account in question:

This was met with more hesitancy but gave the impression that there could be a possibility of compliance and a successful attack:

Another email was sent, that feigned a lack of technical know-how and/or time to do anything different than sending the link that had been sent in earlier emails:

A final email was sent by the target, but by this point, they’d already entered in their credentials trying to access the non-existent file, and the damage was done:

Hauling the catch

At this point, we had everything needed to take over the Domain:

• VPN access gained from a config file retrieved from SharePoint.
• RDP access using an .rdp file discovered in someone’s inbox.
• Domain Admin creds via internal phishing (also known as Business Email Compromise).

It was then possible to RDP onto the Domain Controller as a Domain Administrator, and we were free to do what we liked.

Final Recommendations

Our recommendations to this client were:

1. Security Awareness Training: Provide security awareness training to all staff within the organisation.
2. Implement Multi-Factor Authentication (MFA): Ensure all users set up and use MFA, preferably FIDO2, which is ‘phishing resistant.’
3. Password Managers: Encourage users to use password managers for storing credentials for multiple services. Many allow for multiple users to avoid having to create multiple credentials for a service.
4. Incident Response Plan: Develop an incident response plan that comes into effect once a breach is detected. This will involve Out Of Band (OOB) communication to reduce the chance of attackers eavesdropping on or disrupting communication.
5. Social Engineering Awareness: Educate users on the threat of social engineering pretext attacks.
6. Pretexting Tests: Conduct periodic pretexting attacks against multiple users within the organisation.
7. Business Email Compromise (BEC) Training: Provide security awareness training about the risks of BEC. Emails coming from colleagues’ email addresses can be incredibly convincing – an attacker can look at how the compromised user writes emails, who they speak to regularly, and current/relevant business context to add extra authenticity to their requests.
8. Review Azure Active Directory Roles: Ensure sufficient separation of privileges to avoid a Domain Admin role having an email address attached to that particular ‘admin’ account.
9. MFA for RDP Access: Consider using MFA for RDP access to Domain Controllers.
10. MFA for VPN Access: Consider using MFA for VPN access.

At OmniCyber Security, we’re committed to helping organisations like yours fortify their defences against all threats, including phishing. If you’ve been inspired (or even a bit scared) by this case study and are ready to take action, we invite you to get in touch with our team of experts. We specialise in tailored cybersecurity solutions designed to protect your unique environment.

Don’t wait until you become the next victim of a phishing attack. Reach out to us today to arrange an engagement for your organisation. Our experts are here to guide you through the complex waters of cybersecurity, providing the knowledge and solutions you need to stay secure. Contact us now to embark on a journey toward a safer, more resilient digital future.