Information Security News
Shamoon—the mysterious disk wiper that popped up out nowhere in 2012 and took out more than 35,000 computers in a Saudi Arabian-owned gas company before disappearing—is back. Its new, meaner design has been unleashed three time since November. What's more, a new wiper developed in the same style as Shamoon has been discovered targeting a petroleum company in Europe, where wipers used in the Middle East have not previously been seen.
Researchers from Moscow-based antivirus provider Kaspersky Lab have dubbed the new wiper "StoneDrill." They found it while they were researching the trio of Shamoon attacks, which occurred on two dates in November and one date in late January. The refurbished Shamoon 2.0 added new tools and techniques, including less reliance on outside command-and-control servers, a fully functional ransomware module, and new 32-bit and 64-bit components.
StoneDrill, meanwhile, features an impressive ability to evade detection by, among other things, forgoing the use of disk drivers during installation. To accomplish this, it injects a wiping module into the computer memory associated with the user's preferred browser. StoneDrill also includes backdoor functions that are used for espionage purposes. Kaspersky researchers found four command-and-control panels that the attackers used to steal data from an unknown number of targets. Besides sharing code similarities with Shamoon, StoneDrill also reuses code used in an espionage campaign dubbed "NewsBeef," which targeted organizations around the world.
This is a guest diary submitted by Renato Marinho
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 Santanders attendant. The calls reason? To collect the victims 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 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 companys bank account that required confirmation, otherwise, would be canceled immediately.
Initially, distrusting the phone call, the companys employee asked how the attendant could testify that he was from Santander. The supposed attendant informed that Santander maintains a database with all customers 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 companys account that day.
Continuing the talk, the attendant informed that the companys 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 attendants instruction. He informed that he would call Santander using the number he knows and continue the incident treatment. The attendant accepted the customers decision but, before turning off the phone, insisted on warning the company could lose the money if the reverse operation wasnt done that moment.
After the call end, the targeted employee analyzed in detail the values mentioned by the supposed Santander attendant and realized it were credited inthe companys account and not debited as claimed in the call.
By calling Santander, it also verified that there were no abnormal transactions into the companys 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.
Trying to identify how the criminals have collected the companys bank credentials and accessed the account, we talked to the employee that received the criminals phone call. He told us that he didnt receive any suspicious e-mail or clicked any strange link. The only strange thing that happened that day was an access to Santanders website that asked for the OTP Token combination right after the login. As this unusual, he closed the page and started it over.
By analyzing the browser history, we found this address:
Note that there is a missing n 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.
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 companys 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.
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.
Although typosquatting attacks are not new, this case draws our attention due to no malware usage (unlike Citibanks case last year ) and to the volatility of the information criminals are stealing. Its 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 . 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 devices private key . The downside of this solution are the interoperability problems, since the client application (as the web browser) is directly involved in the authentication process.