SWITCH Security-Blog

SWITCH-CERT IT-Security Blog


1 Comment

Money for Nothing and Coins for Free

Beginning in mid-September 2017, we started seeing a new abuse scheme on .ch and .li domains. The websites in question were running on outdated software and inevitably, hackers exploited some well-known vulnerability in order to inject malicious code. At this point we would usually expect an exploit kit in the website’s content with the purpose of infecting the victim’s machine with malware. In these cases however, the Javascript inject often looked somewhat like the following:

This code is designed to run in the background of the victim’s browser and immediately starts an endless loop of intensive computations at full pace, effectively turning the browser into a hash-crunching mule for the sake of distributed mining of cryptocoins, with profits going directly to the hacker.

Continue reading


16 Comments

94 .ch & .li domain names hijacked and used for drive-by

A Swiss domain holder called us today telling us that the .ch zone points to the wrong name servers for his domain.

The NS entries were ns1.dnshost[.]ga and ns2.dnshost[.]ga. We contacted the registrar and soon realized that this is not the only domain that had unauthorized changes. We identified 93 additional .ch and .li domain names that pointed to the two rogue name servers. While domain hijacking by pointing to a rogue NS is a known attack,  94 domains on a single day is very unusual. So we analyzed what the hijacked domains were used for and soon found out that they are used to infect internet users with malware.

Visitors to the hijacked domains were redirected to the Keitaro TDS (traffic distribution system):

hXXp://46.183.219[.]227/VWcjj6

A TDS decides where to redirect the visitor to, often depending on its IP address (i.e. country),
user agent and operating system.

A dead end may look like the following:

hXXp//46.183.219[.]227/favicon.ico
hXXp://46.183.219[.]227/www.bingo.com

And the visitor will be redirected to Google.

However, in some cases, the visitor is redirected to the Rig Exploit Kit:

hXXp://188.225.87[.]223/?doctor&news=...&;money=...&cars=236&medicine=3848
hXXp://188.225.87[.]223/?health&news=...
...

And the visitor gets infected.

The payload is Neutrino Bot:

MD5: a32f3d0a71a16a461ad94c5bee695988
SHA256: 492081097c78d784be3996d3b823a660f52e0632410ffb2a2a225bd1ec60973d).

It gets in touch with its command and control server and grabs additional modules:

hXXp://poer23[.]tk/tasks.php
hXXp://poer23[.]tk/modules/nn_grabber_x32.dll
hXXp://poer23[.]tk/modules/nn_grabber_x64.dll

A little later, it also gets an update

hXXp//www.araop[.]tk/test.exe

MD5: 7c2864ce7aa0fff3f53fa191c2e63b59
SHA256: c1d60c9fff65bbd0e3156a249ad91873f1719986945f50759b3479a258969b38)

Status

The rogue NS were inserted in the .ch zone file at around 13:00 today. The registrar discovered soon what happened and rolled back the unauthorized changes. At 16:00 all of the changes in the .ch & .li zone were reverted and the NS records pointed to the legitimate name servers again.

[Update 10.7.17 17:15]

Gandi the registrar of the 94 domain names has written a blog post, as well as SCRT the domain holder that initially informed us about the domain name hijacking of scrt.ch. SCRT also showed how Strict Transport Security protected their recurring visitors from being redirected to the bogus website!


Why the most successful Retefe spam campaign never paid off

Switzerland is one of the main targets of the Retefe banking trojan since its first appearance in November 2013. At that time, it changed the local DNS resolver on the computer (See also blog post “Retefe Bankentrojaner” in German only). Almost a year went by until they changed to the still current approach of setting a proxy auto-config (PAC) URL (See also blog post “The Retefe banking Trojan has targeted Switzerland“). To understand the story of this blog post, it helps to understand the modus operandi of the Retefe malware. We recommend you read up on it on our blog links posted above if you are not familiar with it.

While the Retefe actors are constantly changing tactics, for example their newest campaigns also target Mac OS X users, their malware still works the same. One of notable changes was the introduction of Tor in 2016. At first, they started using Tor gateway domain names such as onion.to, onion.link within the proxy auto-config URLs, later on they switched to Tor completely. The advantage of using Tor is of course, anonymity and the difficulty to block or take down the infrastructure.

Onion domain names don’t use DNS or do they?
The Tor network can use .onion domain names but these names are not resolved over DNS but instead work only in the Tor network. RFC 7686 (The “.onion” Special-Use Domain Name) goes into more details on the special case of .onion domain names. However, the fact is that .onion domain names do leak into the DNS system. For potential reasons and more information on this subject we recommend the paper by Versign Labs “Measuring the Leakage of Onion at the Root” (PDF).
Continue reading

Mobile Malware


Adups — The Spy in your Pocket

Smartphones have become inseparable companions of our everyday life. They are so cheap nowadays, you can buy commodity devices running Android OS for less than a hundred Swiss francs. Smartphones aren’t mere wireless telephony devices. They are modern computer systems equipped with a variety of sensors: cameras, microphone, GPS receiver, gyroscopes and accelerometers, etc. They also feature multiple wireless communication interfaces such as multi-generation mobile networking, 2.4 and 5 GHz Wi-Fi, Bluetooth, NFC, etc, which make them a polyvalent communication platform with a quasi permanent Internet connection. Another way of looking at it: using all the components typical smartphones are equipped with, they can be fitted as perfect bugging devices.

On November 15th 2016, Kryptowire published a blog post revealing that „several models of Android mobile devices contained a firmware that collected sensitive personal data about their users and transmitted the data to third-party servers without disclosure or the users’ consent“. The sensitive data includes unique device and user identifiers, but also contact lists, call history, installed applications, and under circumstances text messages as well as fine grained location data. The said firmware originates from Adups, a Shanghai-based company specialized in mobile and IoT technologies. It is part of their FOTA product, a commercial replacement of Google’s Over-The-Air upgrade system, which is used to deploy firmware upgrades to the devices (hence the acronym: Firmware Over The Air). The FOTA component is pre-installed on various brands and models of Android devices manufactured in China. Being installed as a system APK, the software has unrestricted access to all data on the device and cannot be uninstalled.

 

HTTP request originating from a device affected by the Adups backdoor

HTTP request originating from a device affected by the Adups backdoor

Continue reading


6 Comments

Usage of .ch domain names for spamming malware Tofsee stopped

It is rare that a malware family uses .ch or .li domain names in their domain name generation algorithm (DGA). The last time I remember, that we had to take action against a malware using .ch or .li domain names was about 8 years ago. It was Conficker that infected millions of computers worldwide. The malware was generating about 500 .ch and .li domains a day to be potentially used as a command and control server. By then SWITCH joined the conficker working group to prevent the use of domain names by this malware.

Since then we have been watching the use of .ch and .li domain names in malware DGAs and prepared for this by making an agreement with the Registrar of Last Resort (RoLR) to prevent the registration of domain names used in DGA algorithms of malware.

This week the Swiss Govermental Computer Emergency Response Team (GovCERT) informed us about the malware Tofsee using .ch as one of the TLDs in its DGA. Continue reading


A file that wasn’t there

One of our minions (he was introduced in this blog entry a while ago) recently came to us asking for advice: he was about to automate yet another task, by using his Python-fu, and realized that he misses entries in the file system as well as in the registry.

Notably, he only sees this behaviour on 64bit-versions of the Windows operating system:

Windows Explorer (64bit) vs Python application (32bit)

Left: Windows Explorer (64bit) lists several folders and files.   Right: Python application (32bit) only lists the folder Microsoft.

The left image shows the folder C:\Windows\System32\Tasks as seen in the Windows Explorer, the right image as seen in a simple 32bit-python application. Only the subfolder Microsoft is listed there. Something is amiss.

 

Below is the code to produce the right image, when executed in a 32bit-version of Python:

import glob, os
for pathfilename in glob.glob(r"C:\Windows\System32\Tasks\*"):
    print pathfilename

Continue reading


An attachment that wasn’t there

By Slavo Greminger and Oli Schacher

On a daily basis we collect tons of Spam emails, which we analyze for malicious content. Of course, this is not done manually by our thousands of minions, but automated using some Python-fu. Python is a programming language that comes with many libraries, making it easy for us to quickly perform such tasks.

Python’s email library deals with, well, emails. And it does it well. But on October 3rd, we encountered an attachment that wasn’t there – at least according to Python’s email library.

Mal-formatted email

Left: Outlook Web does not show the attachment          Right: Thunderbird does show the attachment

Now how could that happen?

Emails do have a certain structure, which is described nicely in RFC #822, RFC #2822, RFC #5322, RFC #2045, RFC #2046, RFC #2047, RFC #2049, RFC #2231, RFC #4288 and RFC #4289. Even though these RFC’s are clear in their own way, an illustration might help (we focus on multipart emails only) to understand why Python’s email library got fooled.

Continue reading