Token impersonation attacks

Cyber Threats18 Nov 2024

Andy Swift at Six Degrees describes token impersonation attacks and explains why they have broken through multi-factor authentication safeguards

Multi-factor authentication (MFA) has been a cornerstone of online data security and access management for over a decade. But, as cyber-threats become more sophisticated, MFA alone no longer offers across-the-board protection.

Impersonation token attacks are just one example of how MFA’s defensive powers have waned and how cyber-criminals are gaining the advantage—in this case, by tricking users into handing over identity tokens.

So, what can be done to redress the balance, protect victims, and prevent data from falling into the wrong hands?

A brief history of identity management

In ye olde days of access management simple password and username verification was commonplace, used to authenticate to anything from confidential services such as our emails and bank accounts through to our own IT infrastructures.

Threat actors very quickly learnt how easy it was to fool users into handing over those details. Phishing attacks do this elegantly. We all know how they work—lure victim to fake page, make sure it roughly resembles their bank’s website or other log-in page, sit back and wait.

And for all too long, oblivious to the scam, users would enter their credentials, which were then subsequently captured by the threat actor and used to gain access to legitimate sites or, more recently, collected up and sold at market by an access broker.

Service providers and applications countered this threat by introducing a second security layer that required further user verification, and multi-factor authentication finally gained the huge(ish) traction the security community had been crying out for.

These days, it’s usually a push notification via an application, a numeric or alphanumeric code sent as a text message, or an email and valid for just a few minutes. Until recently, this method prevented the vast majority of cyber-criminals from accessing restricted services—even if they had already obtained usernames and passwords.

But cyber-criminals are an ingenious lot. They figured out if they can act as a proxy between the phishing page and legitimate end point, they could not only forward the credentials on to the legitimate site to appear as if the authentication was a success, but they could also intercept authentication tokens returned by the legitimate applications; these in turn can be used by the attacker to hijack what appears to be a legitimate session.

In doing so, they created a supercharged phishing attack known as adversary-in-the-middle (AitM) which can circumvent common MFA safeguards. Indeed, AitM attacks are so effective many experts believe they are now the de facto phishing mechanism for targeting Microsoft 365 environments.

Adversary-in-the-middle attacks

It all starts with a fairly standard looking phishing attack. There is no escaping it, this is still the number one method of entry to capture usernames and passwords en masse. But the twist here is the infrastructure behind the attack also acts as a proxy between the victim and the third party authentication service.

There are several different methods available to cyber-criminals, but the more interesting one plays out as follows:

The victim receives an email taking them to a fake log-in page—just like a traditional, box standard phishing attack. Nothing new here.
The victim enters their username and password—again, just like a traditional phishing attack.
Here’s what’s new: the fake site passes the victim’s username and password credentials to their service provider in real time.
The fake site captures the MFA request from the service provider and passes it back to the victim.
The victim responds to the MFA request by entering the secondary verification details they’ve received via text or email.
Once the user is approved, the attacker can intercept the authentication token issued by the service and use it to open their own session, authenticated as the target user.

Worryingly, you don’t need much in the way of specialist skills to set up an attack like this. A quick search on the public Internet or dark web can uncover ready-made tools designed explicitly for this purpose; some services advertised on the dark web even have pre-built environments for hire with nice front ends for easy configuration.

Boosting MFA with conditional access

Until recently multi-factor authentication was hailed as a silver bullet, but the arrival of impersonation token attacks proves it’s not infallible. The good news, however, is that multi-factor authentication can be strengthened by adding extra identification factors—commonly called conditional access. This allows admins to stipulate additional access conditions on top of the username, password and token.

Admins might require confirmation that the user is requesting access from an authorised location—usually from a list of pre-selected countries—AND that the request is coming from a known/enrolled device. It’s worth noting that these checks are applied transparently in the background, so the user’s experience of MFA remains the same, and they don’t have to enter any further information.

This is a clever counter move against cyber-criminals. Impersonation token attacks succeed because they meet MFA access conditions by providing a username, password and valid token.

But you can identify a potential impersonation token attack if you know the access request has not come from a valid device and/or has originated from abroad, particularly countries like Russia, China or the USA. So, if you set conditional access controls that require log-in from an authorised device AND an authorised location, you can expose the attack early on and block access based on a further rich set of conditional access.

Security, usability and management sensibilities

Conditional access isn’t hard to set up. But tighter access controls can ruffle a few feathers—and, unfortunately, it’s often the senior leadership that takes issue. They may want to work while travelling on business or on holiday (I know, why would you want to!) and find they can’t log in.

Fortunately, it’s possible to add permanent or time-limited exceptions. So, if an IT admin knows that their director will be in America for two weeks, they can raise an exception that allows log-ins from the USA during that time to that single account.

It’s also worth considering a corporate VPN if people within an organisation regularly travel for work. Then, it’s just a case of setting an access control that allows login from authorised devices in any location, as long as its traffic is pushed via the VPN.

Shadow IT – a headache that never goes away

It’s all very well for me to sit here and tell IT teams to mitigate the risk of impersonation token attacks by restricting access to authorised devices. But that means having an up-to-date inventory of all corporate IT assets and authorised third-party devices. The reality is that most companies don’t have a grip on this. As a result, they often have a significant amount of shadow IT—even more so since the mainstream uptake of hybrid working.

So, if you’re looking to establish a list of devices with approved IP addresses, here are a few pointers to get you started:

Catalogue all the official phones, laptops, tablets and PCs within the company—known what devices you want to permit access to where.
Log all operating systems in use on official devices—if you want to get really granular, you can check against known builds and user agents only. Again, any anomalies here might be a reason to block access if it is wildly different.
Prevent people from using unauthorised devices—personally I am not a fan of bring your own device (BYoD), as it feels like a bit of a shortcut and is never as simple as most sandbox vendors may have you believe. It can be done right, and well, but it adds an element of unknown one needs to be prepared to counter.

The limitations of MFA

The rise in impersonation token attacks means that MFA on its own can no longer prevent cyber-criminals from accessing restricted services. One solution is to add conditional access into the mix. This forces users to prove they are working on an authorised machine AND in an authorised location, thereby exposing impersonation token attacks and denying entry to bad actors.

Yet, despite its effectiveness, IT teams are reticent to implement conditional access and this can be for a number of reasons: sometimes it can be workload, ease of integrating and maintaining such rules, or a general unwillingness to experiment with permanent or time-limited exceptions.

As with many IT-related issues, this often comes down to power, authority and budgets. If a senior executive doesn’t want to do something, it’s about finding a middle ground that can work for all. At the end of the day, they too don’t want to put their own organisation at risk.

Andy Swift is Cyber Security Assurance Technical Director at Six Degrees

Main image courtesy of iStockPhoto.com and Natee127