It was a hot July 4th in Washington, DC. I was speaking at a conference in the area and my family decided to attend A Capitol Fourth Celebration that is televised on PBS each year from the steps of the US Capitol. We arrived at the Capitol early, cleared security, got a great spot to view the fireworks and concert, and enjoyed what we thought would be a leisurely afternoon and evening celebrating our nation’s independence. Shortly before the concert began, I started getting odd alerts on my phone. Emails were being sent from our domain that didn’t make sense and the volume of email being sent, on a holiday, certainly didn’t add up. Using only my iPhone, from the steps of the Capitol, I realized someone was sending massive amounts of email from our domain. The email was poorly crafted, and the login page looked nothing like our login page, but a user fell for it and entered their username and password into the phishing site. in. We use Microsoft 365, so I wondered if we had been hacked, or worse yet, if one of our users had been the subject of a phishing attack.
As the concert starting time drew near, my goal was to figure out which account or accounts were compromised so the passwords could be reset to stop the flow of email. I was also trying to get a hold of others on our tech team who were also at BBQs and celebrations for July 4th. Obviously, we had to plug the hole and then, once I could get back to a computer, figure out exactly what happened.
The concert started with me glued to my phone. If you watch the PBS broadcast, you can see me looking at my phone instead of enjoying the start of the concert. By the time the Beach Boys started playing the compromised user account had been shut off and the outgoing email flow stopped. By the time the cannons were firing for the 1812 Overture, all users had been made aware of what happened and been notified that thousands of emails had been sent externally from our domain and email addresses.
After the fireworks ended, and we navigated the crowds back to our hotel, I spent the rest of the night online cleaning up the mess and analyzing exactly what happened and trying to figure out how to make sure I was never caught on national television again cleaning up a mess like this.
What Happened
The bad actors sneakily sent a phishing email to our users pretending to be from Purdue University and asking our users to login using their work credentials to receive a message from Purdue. The email was poorly crafted, and the login page looked nothing like our login page, but a user fell for it and entered their username and password into the phishing site. Choosing a holiday like July 4th was also devilish.
This allowed the bad actors full access to the user’s mailbox from which they immediately started sending tens of thousands of spam messages. The bad actors also had access to our full global address list, which they also spammed, phished, and spoofed.
It would appear their goal was simply to gain access to a valid email server to send as many spam messages as they could before being stopped. These bad actors were probably paid per message they delivered and simply needed an email server from which to send their messages. Fortunately, that is all they did as we found no evidence of file access, data deletion, or even malicious payloads in the emails. They just sent a ton of spam.
We spent the rest of the night cleaning up the bad emails across our Microsoft 365 tenant. Once all the bad emails were removed, we forced numerous password resets. We also had to communicate with those outside our organization who received spam messages from us through the bad actor’s access to our contact lists.
The Solution
Once the accounts were reset our attention turned to prevention. How do you prevent users from being tricked into giving out their usernames and passwords? What safety measures can you implement in case a user gets tricked again? We quickly implemented a 2-pronged strategy.
The first prong was 2 Factor Authentication, also called Multi-Factor Authentication. 2FA or MFA requires the user to login using their username and password and then validate their login using a code or another form of authentication sent directly to them. In the early days 2FA consisted of a text message with a number to your cell phone. Now 2FA can be a text message or any number of authentication apps.
If we had been using 2FA when the user got tricked the bad actors would have attempted to login, the user would have gotten a text message with an authentication code, and the bad actors would have been stopped as they would not have the code from the user.
2FA isn’t perfect, but having it is far better than not having it, trust me. 2FA isn’t convenient, can make support more challenging, and creates headaches for users but the line between security and convenience has to shift more towards security if we are going to protect the data entrusted to us, not to mention our online reputations.
The second prong was improved and increased user training. The person with their fingers on the mouse and keyboard is best positioned to protect your organization. User training would have hopefully prevented the user from being tempted to click the link and enter their credentials.
Up until this point we had sent out occasional warnings but were not using any sort of formal, accountable end user training. Today we are. You can read more about our use of the Human Firewall here.
The Moral of the Story
In this story’s version of happily ever after, don’t be like me. 2FA may be a hassle and may create all sorts of other challenges but it is worth it. Do it before you have to because if you do it when you have to it is already too late and you may have already been spotted on national television trying to cleanup a successful phishing attack.
