(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Enlarge (credit: William Warby)

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.

Read 6 remaining paragraphs | Comments

Symantec Endpoint Protection Client CVE-2016-9093 Local Privilege Escalation Vulnerability
Multiple IBM DB2 Products CVE-2017-1150 Information Disclosure Vulnerability
OpenBSD Man in the Middle Security Bypass Vulnerability
TeX Live CVE-2016-10243 Remote Code Execution Vulnerability
ImageMagick 'coders/psd.c' Local Denial of Service Vulnerability
ImageMagick 'coders/sun.c' Local Heap Buffer Overflow Vulnerability
Symantec Endpoint Protection CVE-2016-9094 Local Command Injection Vulnerability
ImageMagick CVE-2017-6499 Local Denial of Service Vulnerability
WePresent WiPG-1500 Device CVE-2017-6351 Hardcoded Password Security Bypass Vulnerability
ImageMagick CVE-2017-6498 Local Denial of Service Vulnerability
ImageMagick CVE-2017-6501 Local Denial of Service Vulnerability
Wireshark LDSS Dissector 'epan/dissectors/packet-ldss.c' Denial of Service Vulnerability
Sawmill Enterprise v8.7.9 Pass The Hash Authentication Bypass
EasyCom PHP API Stack Buffer Overflow
CVE-2016-7955 - Alienvault OSSIM/USM Authentication Bypass
OpenElec CVE-2017-6445 Man in the Middle Security Bypass Vulnerability
EPESI CVE-2017-6487 Multiple Cross Site Scripting Vulnerabilities
MaNGOSWebV4 CVE-2017-6478 Cross Site Scripting Vulnerability
Groovel CVE-2017-6480 Cross Site Scripting Vulnerability
Dotclear CVE-2017-6446 Multiple Cross Site Scripting Vulnerabilities
Irssi CVE-2017-5356 Denial of Service Vulnerability
ATutor CVE-2017-6483 Multiple Cross Site Scripting Vulnerabilities

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 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 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.

Incident Response

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.

Figure 1 - HTTP redirect evidenceFigure 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 number of the fake website

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 - Fillin the username and password on the fake websiteFigure 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 3: Form asking to type OTP Token Information

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.

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 Citibanks case last year [1]) 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 [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 devices 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.


Renato Marinho

Morphus Labs | linkedin.com/in/renatomarinho | @renato_marinho


[2] https://www.yubico.com/about/background/fido
[3] https://developers.yubico.com/U2F/Protocol_details/Overview.html

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Tcpreplay 'Tcpcapinfo' Utility CVE-2017-6429 Buffer Overflow Vulnerability
OpenEMR CVE-2017-6482 Multiple Cross Site Scripting Vulnerabilities
phpipam CVE-2017-6481 Multiple Cross Site Scripting Vulnerabilities
SilverStripe CMS CVE-2017-5197 Cross Site Scripting Vulnerability
FTPShell Client CVE-2017-6465 Buffer Overflow Vulnerability
SysGauge CVE-2017-6416 Buffer Overflow Vulnerability
Wireshark NetScaler File Parser 'wiretap/netscaler.c' Denial of Service Vulnerability
Piwik Remote Code Execution Vulnerability
Wireshark WSP Dissector 'tcp_graph.c' Denial of Service Vulnerability
sysPass CVE-2017-5999 Cryptographic Security Bypass Vulnerability
OpenElec: Remote Code Execution Vulnerability through Man-In-The-Middle(CVE-2017-6445)
CVE-2017-6430: Out-of-Bounds Read (DOS) Vulnerability in Ettercap Etterfilter utility
Wireshark 'wiretap/netscaler.c' Denial of Service Vulnerability
CVE-2017-6429: Buffer overflow vulnerability in Tcpreplay tcpcapinfo utility
Linux Kernel Vfio Driver CVE-2016-9084 Integer Overflow Vulnerability
rubyzip CVE-2017-5946 Directory Traversal Vulnerability
[SECURITY] [DSA 3801-1] ruby-zip security update
EasyCom SQL iPlug Denial Of Service
Adobe Flash Player APSB17-04 Multiple Heap Buffer Overflow Vulnerabilities
Internet Storm Center Infocon Status