While this is a fictionalised account, real-life situations like these are more common than you might think. Stay vigilant online!
Day 0: The day of the attack
What a relief to have a quiet day, finally! Phew! After helping a customer with a major security incident yesterday, I needed this. What’s on my agenda for today? Work on a report about yesterday’s security event, run some routine system checks, attend a few meetings and call it a day!
Oh, hang on. Here we go again…..
There’s an alert about a suspicious login attempt to a customer’s Finance Director’s account. Thank cyber security Gods, we have an automated script running that quarantines the user account and locks them out.
But how did this even happen?
We are not talking just about anyone here. It’s the Director; of course, it’s a big deal.
I looked through the user activity logs and saw they clicked on a dodgy link.
Now, as you all probably know, this is something you should never do. Hackers are getting smarter than ever, making emails and other communications look like genuine messages from trusted sources.
The Director clicked on a Microsoft portal link that looked genuine. No typos, no fishy text.
Now, I can’t fault them for that because no one’s got time to look at the URL properly, right?
But they should make it. It drives me crazy. 2 seconds tops to check the URL and prevent phishing 101 attacks. 2 seconds. That’s all we ask. .
Hackers will put genuine text first and meddle with domains to make them look real. For example, if you’re supposed to be on google.com, a suspicious link might alter the domain, like google.com.cust_login. In this case, the domain is cust_login and not google.com, and you might think this is a genuine source.
Now, our smart hacker created a URL that looked genuine. Even I might have fallen for it! Okay, maybe not, but you get my drift. So, what happens when you click this link and enter your username and password?
You get prompted for a Multi-Factor Authentication (MFA) sign-in.
MFA is like having an extra lock on your digital door. But now, these sneaky attackers figured out a way to pick that lock with something called the ‘Adversary in the Middle’ infrastructure. Let’s just call it AiM to keep it simple.
When you log in through the AiM infrastructure, they take your username and password and push that through to a legitimate website. From your perspective, everything looks fine. But AiM will take the username and credentials and a copy of the MFA token.
After logging in, you also get a prompt that asks, ‘Do you want to stay logged in for the rest of the session’? Most people click yes.
Innocent enough request, but because you said yes, attackers will take your credentials and MFA token and replay that session against the actual website and will be able to get in, bypassing the MFA controls.
If the attacker succeeded, they would have probably authorised payment for millions from the Finance Director’s credentials and sent it to a dubious bank account.
Thankfully, we fought back with token protection and Azure AD conditional access. Basically, these are policies that check where the user is trying to log in from and which device they are using.
If, say, the login request has come from outside the UK, this will trigger an automated script that prevents the user from logging in, which is exactly what happened in this case.
Now, I’ve got some security awareness sessions to schedule and reports to write to make sure this doesn’t happen to others.
An even bigger challenge is to tell the Director not to click on dodgy links. Gulp. There goes my peaceful day!
Until next time, stay secure and savvy!
