It was recently reported that customers of a Bank in Germany were compromised despite using Two-Factor Authentication (2FA). Granted the second factor of authentication was using SMS, something that National Institute of Standards and Technology (NIST) has deprecated. This hack leveraged the Signaling System #7 (SS7) Network, and should come as no surprise to those of us in the security field. Karsten Nohl helped notify the public about the exploits of the SS7 network back in 2014 and SS7 weaknesses were first reported back in 2008.
This is going to cost the Bank in terms of brand reputation, labor costs, remediation, etc. Based on unique technology developed at SecureAuth, it’s not hard to see how this could have been detected and prevented. At SecureAuth, we don’t believe 2FA is enough, specifically because of scenarios like this. Without a doubt, a growing number of second factor methods can be defeated. That number will only grow as attackers evolve and adapt to changing environments. Let’s walk through how we could map SecureAuth’s Adaptive Authentication capabilities to this Bank’s use case.
Based on public reporting, the customers of this Bank were most likely compromised by reusing a password from a past breach (e.g. a stolen credential). The attack can be assumed to have happened at night during normal sleeping hours. During this SS7 exploitation, the phone was probably switched to a different carrier or the phone number was forwarded. This might have been noticed by a banking customer who was awake and active on their phone.
How could Adaptive Authentication have helped detect this attack? Here are the risk checks that could be been executed if SecureAuth had authenticated the user:
-
DEVICE RECOGNITION: Was this a registered or trusted device of the user? Most likely not, unless the attacker remote access trojan-ed the users’ machine at home or in the office. With the device not being recognized, the bank would have seen this transaction as increased risk.
-
But Bank may not have stopped the user with this information alone. The Bank may not want to inflict unneeded burden on their customers.
-
-
GEO-LOCATION: The German-based customer was logging in from foreign country. This could have been a cause for the transaction to not continue.
-
But let’s say we have a really good attacker and they were able to successfully hide their location.
-
-
GEO-VELOCITY: An “improbable travel event” likely occurred; the German customer logged-in last from their home before bed, but the attackers next login would most likely originate from another country which would make it impossible for the legitimate user to do.
-
But perhaps we have a smarter than average attacker and they spoofed themselves so well, they put themselves within close proximity of the banking customer.
-
-
THREAT SERVICE: Experienced attackers would mask themselves one way or another using Transparent to Anonymous Proxy (TOR). Layering to mask yourself is very common practice when executing an operation of this nature.
-
SecureAuth Threat Service would have identified and allowed the Bank to end the transaction, send notification, and/or request in-person verification — anything other than allowing the transaction to complete.
-
We have now walked through only 4 of the many risk checks provided by SecureAuth Adaptive Authentication. We could say we have more visibility and could have stopped this transaction. But let’s give our attackers more credit – they are smart and cunning. Let’s say they made it past the SecureAuth Threat Service, what else can SecureAuth do to detect and prevent threats:
-
PHONE FRAUD DETECTION: A service to check if the carrier of the number has changed. This would have stopped the SMS from being delivered to any of the banking customers that had a carrier swap from their original phone. We can also check to see if the phone number has recently been ported or the phone type associated with number has changed (e.g. from mobile number to landline, VoIP, etc.)
-
This could have stopped the attackers who switched their targets phone carriers to get the SMS. We have some other information that says some just forwarded the number so this wouldn’t have stopped the attacker. Let’s continue on with the assumption we have some extremely talented attackers.
-
-
USER and ENTITY BEHAVIOR ANALYTICS (UEBA): This check would show that the banking customer never logs into their account at off hours. A historical trend would show there is risk in this user’s behavior and the Bank should stop the transaction or offer an MFA step.
-
This is a little harder to now defeat, because if the attackers wanted to mimic the user’s behavior then they would have had to carry out the attack during daylight or when the target is awake. But for the sake of challenge let’s say they made it past – now what?
-
-
BEHAVIORAL BIOMETRICS: This would be a hard one to defeat for an attacker. They would have to mimic the typing pattern and the mouse movements. A fail of this risk check could end the transaction.
As you can see there are many layers in how we look at truly authenticating a user, including but not limited to 2FA. We believe this is safe, secure, and non-intrusive way to validate a user’s identity and prevent the misuse of stolen credentials. It would take quite a bit of work to defeat all of these risk checks and the attacker would likely have gotten discouraged and moved on to other easier targets.
If some of these risk check had been defeated, SecureAuth would have logged and reported them to a security information and event management (SIEM) system giving the security operations center (SOC) visibility and help analysts correlate threat data from network and endpoint system to track the attack trajectory.
We reached the point where consumers are now adopting 2FA by means of SMS. So it’s finally easier to use! BUT…we also know that 2FA is not enough and multiple risk checks/adaptive authentication can help detect and protect against attacks using SS7, stolen credentials and any number of other vulnerabilities. SecureAuth supports over 25 different authentication methods, some of which do not rely on the SS7 network like Symbol to Accept.
Learn more about how SecureAuth’s layered approach to access control on our Adaptive Authentication page.
To demo SecureAuth Contact Us today!
