An earlier article that I authored outlined, at a high level, the phishing (and more specifically, “Zombie Phishing”) attack that some organisations had fallen victim to. Many of these were large, well-known (and in some instances) international. Of particular interest were some schools, colleges, and Universities as, from my perspective, many in the education sector were stung in part because many of them talk to each other to share information. A big difference here was that unlike it being spread employee to employee like many phishing attacks, this one also bombarded parents and students.
Further to that article, we would like to share some advice around the actions taken by a number of victims regarding how they addressed the matter. A big “Thank You!” to my colleague Michael Fleming at Data#3 for his great input that’s been so valuable in creating this article.
How did this begin?
The victims of this particular Zombie Phishing attack receive emails (often from multiple senders) with a link and legitimate-looking content — such as the sender’s corporate, school, or personal logo. Believing it was real, some users clicked on the link which redirected them to a website with additional sender branding, prompting for the victim to enter their user name and password — which many did.
Without going into too much detail, after entering the victim’s credentials, the attack appears to have used the compromised credentials to leverage the address book and contact list to forward the phishing email onto all internal and external contacts, substituting the content, such as crests and logos, for those of the victim.
How do I manage this?
In some instances, a mail flow rule was created that would prevent future reception of that email as it would inevitably come from others within the same organisation that had been compromised or from others outside the organisation that have also fallen victim. While this may not deal with mutated versions, it controls the immediate threat as an attacker would need to manually intervene to modify the headers sufficiently to circumvent the rule and re-launch the attack. That said, others can do similar and similar variants exist — many with different subjects and spelling.
Another mitigation involved creating a conditional access rule to block access to Exchange Online, SharePoint, OneDrive, and other linked services and applications for anyone outside of the victim’s country. Provided that overseas access isn’t needed and exceptions can be created and managed securely, geoblocking is a powerful countermeasure. I’m unsure how it stands up against a foreign entity using a proxy located in the country of its victim.
Now that we have reacted, what next?
Once the immediate threat was mitigated, a thorough search was undertaken to find and purge malicious mail items with the matching content from mailboxes. This resulted in hundreds, thousands, and in some cases, tens of thousands of items found and purged from mailboxes. Ideally, this prevents someone from re-opening the message and re-igniting the fire.
Further analysis, such as abnormal activity traces were performed. This was done to understand what the then-compromised account may have been used for and what was accessed. In some instances, apart from the email being spread to all internal and external contacts, there did not appear to be data leakage. That said, this was not always the case as some attacks have resulted in unauthorised system and data access requiring further mitigation and investigation leading to, in some cases, a reportable breach.
Local, sovereign laws vary around the world, but in Australia this could be a Breach under the Notifiable Data Breaches amendment to the Privacy Act or in the European Union, a potential breach under the General Data Protection Regulation (GDPR).
What else can we do?
It depends on your situation, but you could consider enforcing Multi-Factor Authentication for all users outside of the private, local network. This means that users will need to type their username + password + MFA code when accessing email externally, but only username + password inside the local, trusted network zone.
Another helpful piece of advice that was shared indicated this issue can be further mitigated on organisation-owned Windows devices by using a hybrid domain-join as a trusted factor so it’s seamlessly providing MFA while remaining secure. This results in a significantly more secure identity posture and should prevent this from occurring in the future.
Of course, there is no substitute for a vigilant workforce! We always recommend ongoing education and awareness, especially when it comes to suspicious emails and all the nefarious things that can result.
How have you coped with your encounters with Zombie Phishing? I’d love to hear your take.
Stay safe out there!
Disclaimer: The thoughts and opinions presented on this blog are my own and not those of any associated third party. The content is provided for general information, educational, and entertainment purposes and does not constitute legal advice or recommendations; it must not be relied upon as such. Appropriate legal advice should be obtained in actual situations. All images, unless otherwise credited, are licensed through ShutterStock