Multi Factor Authentication (MFA) is supposed to protect you from phishing attacks and threat actors who have compromised credentials, yet it’s often bypassed or avoided entirely. The UK governments Cyber Breaches Survey covering 2023 showed that 79% of businesses and 83% of charities suffered a breach or attack via phishing. The same survey revealed over half of UK businesses in 2023 found phishing attacks were the most disruptive attack to them. In this blog I’ll be showing you how MFA is bypassed and what you can do to keep you and your organisation secure.
What is MFA Exactly?
MFA Defined
To prove who you are to an application or service you need to authenticate yourself. Typically this is done with a username and password, known as a single factor of authentication. It’s a single factor of authentication because it consists entirely of details you know. Multi Factor Authentication (MFA) is simply adding other elements to the process so the application or service is more confident in knowing you are indeed you.
Why is adding another (or more) factor of authentication important? Because it reduces the likelihood of someone else impersonating you to that application or service. This is quite important when the functionality provided involves managing your money or interacting with sensitive information such as your emails or organisations data for example.
MFA is often stated to protect against phishing attacks, where a threat actor tricks someone into entering their credentials (username and password) on a malicious website. Whilst MFA won’t stop the credentials being stolen, it should stop them being used as the threat actor will need another factor authentication to actually login. Unless that can be bypassed or avoided entirely of course…
Types of MFA
There are five types of MFA, some are more common than others. MFA as a term is valid when 2 or more factors are utilised. The five types are shown below.
MFA requires some setup before it can be used. Typically websites or services have a setting to turn MFA on which then triggers an enrolment phase. Enrolment is where you, as the user, configure the additional factor(s) you want to use and validate that they work.
The most common example of this is using an MFA App on your phone. Once you’ve enabled the functionality, the website often shows a QR code to scan with an MFA app (such as Microsoft Authenticator or Google Authenticator). This QR code is essentially a square barcode which the app on your phone then decodes into a string of text.
This text is what contains a shared secret and the address of the service to activate the notifications from (if used). The shared secret is typically a short number and randomly generated by the service you just enabled MFA on. The secret is used by the app in conjunction with the current date and time to generate another short string of numbers, known as the MFA code. This MFA code is what’s presented on your phones screen and typically lasts 30 seconds. The following screenshot shows you how this looks once the QR codes decoded.
The service you’re trying to authenticate into also knows this shared secret so is generating the same codes, hence it can check the validity of the codes you enter. A threat actor shouldn’t know this shared secret so won’t be able to generate the right code. A threat actor can cycle through all the possible combinations but it’s unlikely to work within the 30 seconds each code is valid for.
The second most common type of MFA is using a physical token. Sometimes this is similar to a physical representation of your phone app, such as RSA SecureID key fob. These look like this:
This simply has a shared key stored inside some tamper evident hardware. It’s tamper evident because once the case being opened is detected, it blanks the screen and depending on the model can reset itself so it doesn’t generate the correct numbers anymore. It’s important to know that tamper evident means just that, the device responds and signals to a user it has been tampered with. This is different to tamper proof which aims to stop the devices physical security being compromised in any way.
Other hardware devices are available such as Yubikeys, which do not rely on number generators from shared secrets. Instead, these devices work on a concept called public and private cryptography. I’ll give a very high level overview of this as that’s all we need to discuss MFA.
Public and private cryptography is where you, as the user, have two keys. Think of these as two files which have a lot of random characters in them. One file is known as a private key and is never shared. The other file is known as the public key which is freely shared. Both files are related to one another. If someone wants to send you a secret message they encrypt it with your public key, which then means the only thing that can decrypt it is your private key. This protects it from eavesdroppers and also being modified when in transit.
This is great but how do we know it was that person who wrote the message? We use signatures. When they encrypted their message with your public key they also signed it with their private key. When you receive this encrypted message you can check the signature using their public key (you don’t need their private key because the files are related). This then gives you authentication, integrity and confidentiality in the communications.
All this talk of cryptography is great but what’s so special about Yubikeys and their competitors? They use this concept which means there’s no code to be displayed on a screen or be entered. This means you plug the Yubikey or hardware token in, usually through a USB port, tap the button and you’re authenticated. Sometimes that button can be a fingerprint reader to make sure it’s actually you tapping the button and not someone who’s stolen your key but the flow of information doesn’t change.
In the background what’s happening is your Yubikey is encrypting a message using the services public key and signing it with your private key. This helps protect the authentication process from eavesdropping and manipulation. If you connect to a malicious service and use your Yubikey, that won’t be used forwards to the genuine service because the message you encrypted was addressed to the malicious website not the genuine one (and the genuine one uses a different set of keys). Here’s what a Yubikey looks like.
A Yubikey Device
The last common factor of additional authentication we’ll cover is the geolocation aspect. This sometimes is used in personal services, such as geofencing where you don’t need to supply additional details (such as an MFA token) if you are geographically located in a certain area such as around your own property. It’s commonly used in enterprise situations where MFA tends not to be required if resources are being access from an organisations internal network yet remote workers are required to supply additional authentication factors.
MFA Bypass Techniques
Now we’ve learned about what MFA is and the various types that can be used, lets get into how these protections around authentication can be bypassed. Firstly though, lets view this task from a threat actors perspective.
What do threat actors actually want? They certainly don’t want to show off technically and they also don’t want to get caught. We often fall into the trap of personalising threat actors and miss the core objectives they have. We view them as individuals who are nefariously targeting an individual or organisation when in reality, it’s just business to them. Threat actors can be an individual, team, organised crime group or a fully fledged nation state. We also often forget that sometimes no humans are involved, with a substantial number of attacks being automated by threat actors and associated malware.
Threat actors want to obtain access, interact with your systems / services and ultimately achieve an objective they have. Threat actors are interested in the path of least resistance. They are there to optimise their return on investment and minimise their risks. Knowing and being able to utilise this perspective can help us to reframe how we go about defending ourselves effectively.
Avoiding MFA Entirely
With the new found perspective of a threat actor, lets look at why we want to target MFA in the first place. If a threat actor wants to access the data or conduct an action in an application or service protected by MFA then the easiest way is to avoid MFA altogether.
MFA is there to protect the authentication process, it does not protect the underlying application. Put simply, threat actors will target vulnerabilities in the application versus circumventing authentication requirements.
There are a number of useful vulnerabilities for this, the first one is cross-site request forgery. This is where a threat actor tricks a user into interacting with a website on their behalf. Cross-site request forgery is often achieved by encouraging the user to browse to a third party website which contains code that gets the users browser to make the request to the target application. This doesn’t require clicking of a link in a lot of cases, as it’s triggered through attempting to load an image which is the threat actors request to the target application. As a simplified example the following code snippet is how a website would normally load an image:
<img src="companylogo.jpg">Whereas a malicious one that may try and send money to the threat actor can be seen below. Instead of looking for an image file it simply gets the users browser to load the URL.
<img src="http://targetwebsite.com/sendpaypal.php?recipient=cash@threatactor.com&amount=100000¤cy=GBP&approved=true">If the application was vulnerable to cross-site request forgery then the payment would have been sent, all without any MFA being required. It doesn’t ned authentication because the users browser will helpfully add the session cookies to the request. These session cookies are what’s used to keep you authenticated to a website and stops you from needing to keep logging in for each page you visit. As long as the user is authenticated (or hasn’t logged out) when that request is sent, it’ll be handled as if they browsed to the page legitimately.
What we can see here is that a threat actor has achieved their objective without even considering the MFA in place. As a fun fact, most competitor penetration testing reports we’ve seen show cross-site requesting forgery as low risk, having a negligible impact – yet it voids all the additional protection of having MFA.
Another example is reflected cross-site scripting, which is where the user is tricked into clicking a link which then runs JavaScript inside the vulnerable websites page. A website is vulnerable when it reflects user input back to the user without appropriate sanitisation. This may not sound serious, but it allows those all essential session cookies to be stolen (if they aren’t protected appropriately) and sent back to the threat actor.
The attacks possible through cross-site scripting are not just limited to stealing cookies, it can also be used to exfiltrate data out of a website and be used to launched cross-site request forgery attacks. This is very useful when there’s defences in place to stop cross-site request forgery, as using cross-site scripting a threat actor can circumvent these protections. A basic flow of a cross-site scripting can be seen below.
When websites are developed they often include Application Programming Interfaces (APIs). APIs are interfaces that typically expose the same functionality in the application, sometimes a few more functions too, but are designed to be accessed programmatically i.e. by a machine not a human. Developers needs to test the API works and it’s quite common to see a piece of software called Postman utilised.
Postman is installed on the developers machine or in the testing environment and simplifies the making of requests to the API. However, Postman also offers to store the project, which includes the requests to be sent to the API, in the cloud. If the permissions are not set correctly on this cloud storage, the requests can be accessible by searching the Postman project repositories. This is incredibly useful given that it’s a common development practice to store the authentication tokens in the requests used to test the API. If you’re thinking that’s an easy win for the threat actor, you’d be right.
Instead of targeting the heavily fortified entrance to the application, the threat actor will look for the least resistance. APIs typically offer less resistance in terms of security defences in place. When this is paired with insecure development practices it can resulting in authentication tokens being disclosed publicly. All a threat actor needs to do is search for the token and use the sample request provided and they’re well on their way to hitting that objective.
Another way of avoiding MFA requirements is for the threat actor to identify legacy authentication portals which were never updated to support an MFA prompt. These are more common than you may think and is why many cloud providers such as Microsoft’s Azure encourage administrators to disable legacy authentication methods.
The last common way of avoiding an MFA requirement is to attempt the login with the username and password and on the prompt for MFA select an alternative option. This option may be an alternative challenge that’s offered, such as providing a piece of memorable information for example. Ironically this secondary request wouldn’t be classified as a secondary authentication because it is also “something you know” in the same way a username and password is.
A lot of applications will offer additional recovery options in the event a user has lost their MFA. These recovery options sometimes can be reliant on single use codes or providing a reset link to the registered email address as examples. This then means the threat actor just needs to find the right service, such as a webmail account, which either doesn’t support MFA or has not had it enabled and that’s their way into the recovery process to bypass the MFA requirement.
Bypassing MFA
Sometimes it’s not possible for a threat actor to avoid MFA and that’s where the lateral thought of a malicious mindset can help.
Outsourcing MFA Completion
Bearing in mind threat actors like the easy path, the first technique we’ll cover is simply outsourcing the completion of the MFA to the real end user (the victim). This can be as simple as adding another layer to capability to a phishing attack.
During a phishing attack, the victim is tricked into entering their credentials into a seemingly legitimate website, such as a corporate Microsoft 365 portal for example. This portal then siphons off the submitted username and password for the threat actor to utilise later but when MFA is required this attack is impeded, because the threat actor doesn’t have the MFA access.
To get around this problem, the threat actor can deploy additional functionality into their malicious website to pass the credentials onto the legitimate website and then request the MFA token from the victim. If the victim enters their MFA token this is then relayed onto the legitimate website again and a valid authenticated session created. The session tokens, which are typically web cookies, are then sent onto the threat actor who is now able to utilise the same resources that the victim could in a genuine use case. The capability to launch this attack is simple and available to any threat actor. Tools such as Evilginx (https://github.com/kgretzky/evilginx2) for example, do all the hard work for the threat actor and is a framework that allows very customised attacks.
Tools like Evilginx are essentially reverse proxying the victims access to the legitimate website, hence why they can offer secure HTTPS services to the victims and still connect to the target service via secure HTTPS, without any warning to a victim. This type of attack works well against one time number based MFA setups (be them phone app based or hardware based like RSA SecurID key fobs). It does not work against FIDO (https://fidoalliance.org/) style MFA solutions, such as Yubikeys etc. The following diagram shows how this attack works in practice.
Account Role Targeting
Another trick in the threat actors playbook is to spot the pitfall in common guidance given to organisations about enforcing MFA. Most guidance states to start the MFA rollout focusing only on the privileged users i.e. administrators or those who are senior in an organisation. This means that organisations often leave standard user accounts without MFA for a period of time. Some choose to never enforce the requirement on this category of user. This is where the threat actor can bypass the MFA requirement by simply targeting accounts of lower privileged users. This may seem counterintuitive because a popular belief is that threat actors desire high privileges and target administrative accounts first.
The reality is, to meet a threat actors objective, a standard user account may have enough access. Completing the objective is the threat actors focus so why would they increase the risk of difficulty, and likelihood of being caught, by attacking a category of account everyone is worried about and watching closely in the security operations centre? An example of this would be intellectual property theft.
In most organisations a standard user account can search and download content from the company’s internal SharePoint instance and network shares without restriction, so if that’s the data the threat actors after what more do they need? Another key point is to remember that threat actors work in stages, they may only need to obtain access internally so they can escalate privileges later and because all activity is then internal, there’s no MFA challenge to circumvent.
Threat actors also target the other accounts which may not have MFA enforced. Organisations often overlook or choose not to disable logon rights with service accounts (which don’t have MFA on them). A lack of MFA isn’t the vulnerability here, it’s the ability to authenticate with the service account but from a threat actors perspective it’s a valid way of bypassing MFA. Whilst service accounts more than often won’t have the same access as a genuine user account they do allow for additional attacks to be launched. To a threat actor struggling to obtain that initial access, even a semi-restricted level of access is better than nothing.
Suppliers to Threat Actors
How an organisation manages its suppliers access is also an interesting avenue of attack for a threat actor. if the organisation trusts the suppliers own accounts through federation, then there needs to be checks that those accounts do have MFA enabled else it provides a simple way of bypassing MFA. It also poses an interesting choice around if the organisation enforces MFA on the federated account inside the organisation or if they trust the supplier to manage the MFA on their own accounts.
For instances where the supplier is given direct access accounts inside the organisation, these accounts sometimes are left without MFA because they’re seen as only providing limited access and the desire is to avoid the administrative overhead of enforcing MFA to partner organisations. A threat actor will take the time to identify the accounts which yield the best result for them and all of a sudden that low risk user enumeration vulnerability you have in an authentication portal just increased in risk severity.
Enforced But Not Enrolled
If MFA is enforced on all accounts in an organisation, there may be a feeling of safety. However, enforcing is only the first stage as users do need to setup the MFA on their accounts. Threat actors will leverage the time delay for the second part of this process by identifying accounts that have yet to setup MFA. This allows threat actors to utilise compromised credentials (through guessing or shared credentials etc) and setup MFA for the account. This not only provides them further access but also has the added benefit of reducing the ability for the victim to report the attack as they’ll need the threat actors MFA details to authenticate themselves into the system so now need to report it out of band.
Trusting Networks
When MFA is triggered is part of what a threat actor enumerates. A lot of organisations trust their internal network, so if a logon attempt to a website is made from their physical office then no MFA is needed. This may sound sensible and pragmatic because a threat actor would need to break into the office to bypass MFA surely? In truth this is another area where a threat actors mindset it useful in joining together several points.
Knowing that most organisations have this internal trust, we know that it’s likely defined by an IP address range that the users come from. This means the threat actor needs to come from the same IP address range, so the threat actor needs access to the network right? Yes and no, because most organisations provide guest wireless access to visitors. It often requires no authentication to join and the more security mature organisations keep it segregated away from the internal network. However most organisations route all the traffic destined to the Internet out of the same connection.
This might sound a non-risk but it means that a threat actor connected to your guest wireless network likely won’t be prompted for MFA, because the IP address they’re coming from is the same one as your employees. This still requires a threat actor to physically be near the target organisation. For some threat actors that’s a simple requirement to be meet logistically but for others it can be more involved. It all comes down to the threat actors resources and determination – they could choose to attack an organisation physically nearby to then pivot onto the guest wireless network of their ultimate target for example.
Trusting Devices
Trusted devices are another avenue of attack for a threat actor. Organisations sometimes will only prompt for MFA on devices that are not enrolled as part of the companies IT management solution. This means that the focus of the attack will shift from getting a victim to supply their credentials to a more hybrid attack where a user is tricked into running a malicious payload or exploit. These types of attacks gift the threat actor access to the underlying machine the victim is utilising and allows the threat actor to interact with web services and other internal resources without the impedance of MFA.
In a similar vein to the exploitation of enforced but not activated MFA on user accounts, there is often a self-service portal for organisations that allows the enrolment of devices. Threat actors can use this, if left unprotected, to enrol a virtual machine to an organisations IT management system and therefore bypass the need to provide MFA alongside any of the credentials they have compromised.
Accessing MFA Directly
Threat actors are focused on an objective, they won’t think twice about targeting an individual to exploit their access inside a target organisation. When an organisation enforces MFA the users need to be able to generate their one time codes or approve the sign in request. Most of the time this is done through a mobile app.
As we saw in the overview section of this blog post, there is a shared secret that’s used to generate the codes. This shared secret is a target for any threat actor and if the mobile phone is outdated then it may be remotely exploitable in which case a threat actor may be able to extract the shared secret and use it to generate their own codes. Modern mobile operating systems are increasingly robust from a security perspective and the shared secret is typically stored in protected areas but threat actors attacks are increasingly refined too. If the phone is backed up to an insecure location, or the backup is compromised then the shared secrets can be recovered.
Additionally, during the enrolment stage, particularly for QR code based enrolments, there’s nothing to stop that MFA secret being stored on a personal device instead of the organisations one. This opens up an interesting attack avenue because whilst the organisations mobile devices might have undergone security hardening, the user may be using a jailbroken phone with malware on it. In fact, most modern malware variants such as the Escobar Android strain of malware automatically target MFA apps on victims phones, allowing the access obtained to be sent back to whoever is running the specific malware campaign.
Tired of MFA
Human behaviour is also an area targeted by threat actors. MFA can be configured to send an alert, requiring approval to sign in, to a mobile phone app. Threat actors know that it’s likely the intended user won’t click approve on a random sign in request. However, they also know that there’s a few ways of encouraging the user to approve that sign in request. This can either be through timing, such as generating that MFA alert when the user is likely to start work. This increases the chances of success because users might think it’s related to the sign in request they legitimately have completed recently.
Threat actors also know the humans have a limited amount of patience and so generate hundreds of MFA alerts to the user. This will frustrate them as the prompts will distract from whatever else they want to do. This frustration then drives users to approve the sign in request just to stop the alerts. If a user is particularly resilient to this sort of alert fatigue based attack then a secondary communication channel is often opened up where the IT support team are impersonated and advise the user to approve the request for a seemingly sensible reason.
Some modern MFA solutions are now actively defending against this type of attack. Microsoft introduced its matching numbers style authentication in May 2023. This is where the user of the app needs to input the number presented on the login screen for the website. This means the threat actor now needs to provide the right number for the user to enter which substantially lowers the effectiveness of MFA fatigue attacks.
To further reduce the number of alerts received by users, Microsoft also stopped sending the alerts when a “risky login” was detected. This is where the sign in attempt comes from an unfamiliar location or exhibits other unusual activity and means that the target user never even sees the MFA prompt.
Fake MFA Apps
Whilst MFA offers another layer of protection to an authentication process, they do require users to download a mobile app typically (except where hardware keys or another factor is used). Threat actors see this dependency and create fake MFA apps that operate in exactly the same way as Google Authenticator and Microsoft Authenticator. However the difference is these apps send the shared secret to the developer who either is, or sells on the information to, a threat actor.
This means a threat actor needs to coerce or trick a user into using the MFA app over a genuine one. They can do this by creating a malicious MFA app and getting it published to a trusted store e.g. Apple’s App Store or the Google Play store. Threat actors then trick users into downloading it by paying for sponsored search results so that when a user searches for MFA apps they find the malicious one at the top of the results page, increasing the likelihood the user will download it. The mobile app stores do detect this behaviour, but it is always an arms race between the threat actors uploading new apps and the app stores investigating and removing the known malicious ones.
A more targeted mechanism used by threat actors is to brand an MFA app with a target organisations logo and name. This can build trust in the MFA app from users and sometimes does not even require advertising as employees of an organisation have been known to install apps that they believe are from their employer when browsing the app stores. When pushed for time, threat actors can use this malicious app in conjunction with a phishing email to coerce users into updating their MFA to utilise the new company specific MFA app. This then provides the threat actor with the ability to bypass the MFA requirement, as they are in possession of the users MFA details.
Hardware Attacks
We’ve discussed a lot about MFA when it’s provided through mobile apps but what if the organisation has implemented hardware tokens? Some of the attacks are nullified by the way a physical MFA device (such as a Yubikey) works. However, there are still several avenues open to a threat actor. It should be noted these require a technical step up in terms of capability, both to identify and to exploit any vulnerability.
One of the most prominent attacks against hardware tokens was against Yubikeys. The vulnerability exploited was the ability for a phishing site to interact with a connected Yubikey through a feature known as WebUSB in the Chrome web browser. In normal usage, a website requesting MFA from a Yubikey utilises a dedicated authentication function in the users browsers (U2F in Chrome’s case). This dedicated functionality ensures that the website requesting the MFA authentication is indeed a legitimate one and is not a phishing website.
However, when WebUSB was utilised, the website can interact with the Yubikey without any checks being made on the validity of the website. This allowed a phishing site to launch a man-in-the-middle attack just like with code based MFA attacks. It should be noted that the vulnerability sat within the Chrome browser, rather than the Yubikey, and was patched after discovery but it goes to show attacks are still possible.
Hardware devices, such as Yubikeys also need to be managed as assets of the organisation. They require updating as they have firmware and software components. Threat actors often undertake research to identify vulnerabilities in systems and MFA hardware devices are no different. An example of this was the Near Field Communication (NFC) vulnerability in certain models of Yubikeys, which could result in a threat actor bypassing any protection PINs configured on the device. This was patched by a firmware update but goes to show the importance of seeing these devices as assets to be managed.
We also need to consider the physical threat actor here. Theft of devices is still a rampant problem and most users will keep their MFA hardware device in close proximity to their laptop. This means if the laptop is stolen, there’s a good chance the MFA hardware will be stolen too. Whilst this sometimes would require knowledge of the users password to login and use the MFA device, often the laptop is configured to use the same MFA token in a password less fashion. This means the threat actor, or thief in this case, simply needs to insert the hardware token and power on the laptop. Some MFA devices require a fingerprint which would limit this attack but most only require a button to be pushed to approve the authentication on the device.
MFA as an Attack Vector
To make MFA work in an organisation, it can require new infrastructure components to be deployed. It’s important to recognise this increase in attack surface available to a threat actor.
Hosting Infrastructure & Misconfigurations
With new infrastructure comes more servers to manage and the inevitable challenge of securing them from both external and insider threats. Deploying MFA can require key material to be stored and authentication providers to be configured inside the organisation. This in short means new servers will be deployed and they will be a target for threat actors. If these are not kept updated then it is likely they will be the subject of a compromise, either by automated malware inside the organisation or they may even be exposed externally through misconfiguration of a firewall for example. Patches for these services is quite common and their exposure quite broad given the number of third party libraries in use, as can be seen in this RSA SecurID security advisory https://community.rsa.com/s/article/RSA-2023-12-RSA-Authentication-Manager-Security-Update-for-Third-Party-Component-Vulnerabilities
How these servers are managed becomes of interest for threat actors too. A threat actor typically desires persistence in an environment i.e. to keep the foothold they have worked to acquire. This can be through remote command and control setups, where beacons (calls) are sent out from the organisation back to the threat actor which then provides commands to run. However, there is a risk this can be detected by a security operations centre.
One option threat actors have been using to obtain persistence with lesser risk of detection is to impersonate a valid end users access. If MFA is deployed in the organisation clearly this would provide a hurdle to authenticating in as that user. This is where those servers holding the MFA secrets become useful, as stealing the authentication data or backdooring the process can allow for continued access by the threat actor.
Breaking Glass
When things go wrong organisations often default to a break glass account. It’s a bit like breaking glass on the fire alarm switch, only to be done in an emergency. These accounts are typically utilised when the MFA provider has gone down or there’s another issue that’s stopping access through normal channels. For this reason they are often configured with high privileges, such as global administrator in Microsoft Azure, and have MFA disabled (else how would they work in a break-glass scenario).
Threat actors will expend effort in identifying these accounts, because they’re typically only protected with a password and are also excluded from lockout policies (given their emergency use case definition). If these accounts aren’t suitably monitored and have a long and complex password then they can allow a threat actor widespread access to an organisation.
Dependencies
MFA by its definition adds another layer to the authentication process but this also adds a dependency. As an organisation there’s an inherent trust that the MFA will not only remain operational but be free of security compromise. This isn’t always the case as we saw affect RSA, the organisation which provides the RSA SecurID hardware fobs that generate number sequences to be used at an MFA prompt.
In 2011 it was reported that RSA was subjected to a “extremely sophisticated cyber attack” which transpired to be a targeted phishing attack. The result of which was an employee opening an attached Microsoft Excel file, that contained and ran an exploit for Adobe Flash which provided the threat actor code execution abilities. From this point, the threat actor moved around inside RSAs network. It was reported that they stole the secrets to the number generation routine, known as seed values and the associated hardware serial numbers of the devices they were input into. This type of data would allow a threat actor to generate valid codes if they knew the serial number in use on an account.
It was subsequently reported in June of 2011 that Lockheed Martin was subjected to a cyber attack, which as allegedly related to the breach of RSA earlier in the year. RSA offered to replace tokens for more than 30,000 of its customers to keep them secure. This goes to show that all dependencies, whether related to a security product or not, need to be managed securely.
Keeping Yourself Safe
So, what’s the answer here? Do we still want to use MFA? Absolutely but it must be deployed securely and with oversight to the ongoing risks. It’s also of upmost importance to understand that MFA is a mitigation to a range of attacks but it is not a replacement for robust identity management in your organisation.
Let’s look at some things to keep in mind with regards to MFA:
Don’t forget, we’re here to help and can show you where your risks are and how best to manage them. Why not have a look at our web application assessments to see if your applications have vulnerabilities? You can also find out your external risks through our external infrastructure assessments.
Alternatively pop your details into the form below and an experienced consultant will be happy to provide some advice.