Distracted users mistyping the first “n” when accessing www.santanderempresarial.com.br are subject to banking credentials theft and a very convincing phone call from a pretended Santander’s attendant. The call’s reason? To collect the victim’s OTP Token combination and proceed with previously prepared fraudulent.

This is the exact scenario we witnessed this week during an incident response procedure and that is detailed in this diary. In the end, I bring considerations and reflections on OTP Tokens effectiveness as a second factor authentication solution.

The phone call

The employee in charge of the financial sector of the targeted company received a phone call from a supposed Santander Bank attendant. The supposed attendant informed that suspicious transactions were identified in the company’s bank account that required confirmation, otherwise, would be canceled immediately.

Initially, distrusting the phone call, the company’s employee asked how the attendant could testify that he was from Santander. The supposed attendant informed that Santander maintains a database with all customer’s details and started saying the full name of the account owner, his CPF (SSN EUA equivalent), registered phone numbers and even details about the machine from which the transactions was made, like IP address, operating system, and Internet browser to attest credibility. All the information was correct.

The attendant continued by asking about those suspected transactions but this time he informs the values: R$ 5.330,00 and R$ 10.083,15. Intriguingly, transactions with those values were made in the company’s account that day.

Continuing the talk, the attendant informed that the company’s employee had failed to accomplish an important security step during his access to the bank website and should be wary as many fraudulent transactions happened in the past years (later, we realized that the missing step was the OTP combination typing in the fake website).

Even after so many confirmations, the employee decided not to follow the attendant’s instruction. He informed that he would call Santander using the number he knows and continue the incident treatment. The attendant accepted the customer’s decision but, before turning off the phone, insisted on warning the company could lose the money if the reverse operation wasn’t done that moment.

Misinformation

After the call end, the targeted employee analyzed in detail the values mentioned by the supposed Santander attendant and realized it were credited in the company’s account and not debited as claimed in the call.

By calling Santander, it also verified that there were no abnormal transactions into the company’s bank account and that the bank did not call them that day for any reason. In other words, it was a fraud attempt. From that moment on, all the passwords and account access were blocked by Santander to avoid further violations.

Incident Response

Trying to identify how the criminals have collected the company’s bank credentials and accessed the account, we talked to the employee that received the criminal’s phone call. He told us that he didn’t receive any suspicious e-mail or clicked any strange link. The only strange thing that happened that day was an access to Santander’s website that asked for the OTP Token combination right after the login. As this unusual, he closed the page and started it over.

So, I tried reaching the mistyped address in order to confirm the typosquatting attack but curiously the content I found was an output from the phpinfo() command; and not a fake Santander website, as expected. Just after trying to access using another public IP address, I was able to reach the fake website. It seems the fraudsters included its victims’ IP addresses in some kind of block list to mislead an incident responder.

Right after we accessed the fake Santander website, it went offline. Would they be perceiving our analysis or was it just due to the end of office hours? It sounds like a joke, but it does make sense. This is the kind of attack that requires immediate action and possible real-time interaction with the victim to be successful due to the OTP Token data volatility. Confirming our theory, the website came back next day 8-AM and, we finally could proceed with the analysis.

Using a lab computer, we accessed the typosquatting address while capturing the network traffic and realized the HTTP response was redirecting http://www.satanderempresarial.com.br to http://acessoempresarial.890m.com/netibe, as shown in Figure 1.

Figure 1: HTTP redirect evidence

Following the target company employee steps, I started to fill the forms with random information, as seen in Figure 2.

Figure 2: Filling in bank agency and account numbers on the fake website

As expected, there was no form validation in place. On the next page, they ask us to type the username and password as seen in Figure 3.

Figure 3: Filling the username and password on the fake website

Again, no validation. We were taken to a form asking the following fields: electronic signature, Token serial number and OTP combination, as seen in Figure 4.

Figure 4: Form asking to type OTP Token Information

If the target company employee reached this form, it was sure he had filled the previous forms with all the information necessary for the criminals to access his company’s bank account – and that explains how the supposed Santander attendant confirmed all those data during the phone call. It also explains the call reason. They were trying to obtain the OTP Token combinations to proceed with fraudulent operations and, as they argued two suspected transactions, they were likely to ask the victim at least two OTP codes.

Indicators of Compromise (IOCs)

During this work, in addition to the addresses directly involved in the treated incident, we found other 27 “.br” domains owned by the same person and possible used in similar campaigns against Santander and Itau banks, as shown below.

Final considerations

Although typosquatting attacks are not new, this case draws our attention due to no malware usage (unlike Citibank’s case last year [1]) and to the volatility of the information criminals are stealing. It’s a kind of interactive and limited-scale attack that reminds us of the risks of using OTP Tokens on a multi-factor authentication.

There is no doubt about the increased protection delivered by these devices, but, due to the fact the code may be captured on man-in-the-middle or typosquatting attacks and replayed, it may be inadequately as the possession factor compound in a two-factor authentication.

It would be more appropriate to use a real-time challenge/response solution such as those employed by the U2F (Universal 2nd Factor) standard [2]. Those solutions implement public-key cryptography, phishing and man-in-the-middle protections by digitally signing the response, origin URI and TLS Channel ID with U2F device’s private key [3]. The downside of this solution are the interoperability problems, since the client application (as the web browser) is directly involved in the authentication process.