Two of our users sent out emails that looked like the below this week. The subject was “Dropbox Important”
The e-mails came from trusted e-mail accounts within the organization, and a few more people opened the email.
Once they opened the e-mail, they went ahead and opened the attachment, finding a “Dropbox Business” logon screen – they proceeded to enter their office365 credentials and hit submit.
1. This is not just the users fault, IT have failed by letting this e-mail enter their inbox in the first place.
2. IT also failed to have any sort of anti-phishing automation in place. Credentials left the network unimpeded, in clear-text.
3. IT also failed in our education of users on a whole heap of approaches.
How do we fix this?
First off, with a budding obsession in InfoSec I wanted to stop any further credentials from being leaked in case other users picked up the e-mail a few days later. I opened the .html attachment in an isolated VM (overkill, but this was my first attempt at digging into a phishing attack on company time – playing it safe seemed the route to take) and quickly saw a very basic submit form to a back-end server with a .com domain. A bit of whois, ping & nslookup quickly showed me the site was being hosted on the Google Compute Platform – a few e-mails and a couple of hours later the back-end was gone. Now anyone who entered credentials into that version of the .html file would not lose their credentials to whoever was behind this. We knew it wouldn’t take long for a new domain to be used and an updated version of the .html file seen.
We also ran an audit of our office365 accounts to check if any forwarders had been set up…they had. Anyone who had entered their credentials was now receiving no e-mail – everything being forwarded out to an @aol.com account with no local copies retained. Great.
With the forwarders removed, and the powershell now running every 24hours to alert us in case that changes, we wrote to all our users reminding them to obey basic security principles and laid out some basics. Within minutes we get another version of the email come out from another internal user, we even had one user reply to the advice e-mail asking if it itself was a phishing attack.
Why were these e-mails even making it to peoples’ inboxes?
Cue deep dive of Microsoft ATA & ATP.
Anything suspect now comes directly to our helpdesk via a Jira ticket – attachments are scanned and opened in isolation and then sent onto the end-users.
It’s going to be a slow process of fine tuning these settings, i’ll report back when we’ve found those sweet spots and can offer some more detailed advice on what worked for us.
If you’re reading this as a non-techie, do us all a favour and DON’T OPEN THAT E-MAIL!!!