Malware Alerts

Subscribe to Malware Alerts feed Malware Alerts
Online headquarters of Kaspersky Lab security experts.
Updated: 48 min 42 sec ago

An increase of sophisticated phishing attacks in Sweden

Wed, 07/06/2016 - 12:13

Whilst sitting and working in the South African office I receive an email from my Swedish ISP. I quickly look at it and there is something that doesn’t add up. The email states that I need to pay my invoice, but I never receive electronic invoices from this company.

Like everyone else I receive a lot of spam and phishing emails, but this one is different from any other phishing email I have ever seen before. To be honest, it’s probably the most sophisticated phishing campaign that I’ve ever encountered. It’s not the technical setup that makes it sophisticated it is a very simple factor that has been added to the email that just makes the email look very authentic.

The phishing campaign has the usual mistakes, the sender of the email is not related to the company, and the domains used in the links don’t point to a domain that is registered by the ISP.

There has been a huge increase in these kind of phishing emails lately but it’s the first time I have seen these emails. What makes this campaign so interesting is that they have not just addressed the email to me, but also included my child’s name. This is something I have never seen before. How they got access to my child´s name is not sure, one speculation is that they compromised a Swedish governmental agency, but this has to be left unconfirmed.

What happens when you click on the link is it will redirect you to a website. This website will enumerate from your country of residence to make sure that you are actually a Swedish victim. Additional to this, it will enumerate your browser by analysing the User-Agent string.

Why they check the Operating System is because the next step in the campaign is to trick you into downloading a Windows executable. We are currently investigating what the malware is doing, but from our previous research it seems that it’s some kind of Cryptolocker.

The download page looks very authentic, it even uses the domain (translated to, with a little captcha. When you click on the download button you will be offered a ZIP-file.

This archive contains an obfuscated JavaScript which will then download the actual Windows executable. Even though the JavaScript is obfuscated the download URL is not, so it’s very easy for any researcher to get hold of the malware, and block it. Below is a script of the obfuscated JavaScript.

When analysing the landing pages and the source code i found something that was quite interesting. The language of the HTML editor that was used is Russian, and some of the domains are registered to an email address, which has registered other domains in Russia. This might be an indicator that the persons behind this scam has Russian origin.

Surges in mobile energy consumption during USB charging and data exchange

Wed, 07/06/2016 - 05:53

Recently, our colleagues questioned the security of charging mobile devices via USB ports. They discovered that if there were a computer behind the port, there would be a data exchange, even when the mobile is blocked. We became curious – is it possible to measure the energy consumption of the “host + mobile” system during handshakes? Also, is it possible to estimate the impact on energy consumption when we separate the charging process from data exchange using the Pure.Charger device?

As it turned out, it wasn’t too hard to measure energy consumption – all it takes is a commercially available multimeter, preferably, with serial connection to a computer, which would allow you to analyze logs in a convenient manner. It was possible to provide a rough estimate of how much energy is dissipated during handshakes and to estimate to a known degree of certainty the amount of energy required to send one bit of data over the USB connection.

A little bit of theory

Dissipation of electrical energy into heat is due to two key reasons, the first being the imperfection of even the most modern computers and the second being the irreversibility of classic (non-quantum) computing.

The fundamental limit on energy consumption can be estimated using Landauer’s principle, first introduced in 1961: ∂Q = dS · T = kTln(2), which is equal to roughly 3×10-21 Joules (J) at room temperature. In reality, computation and, especially, data transfer is much more energy-hungry. We learned from a 2014 review by Coroama and Hilty, published in Environmental Impact Assessment Review, that it takes approximately 4×10-7 Joules per bit to transfer data over the Internet. That is 14 orders of magnitude above the fundamental limit.

Unfortunately, we haven’t been able to find similarly thorough and high-quality reports on energy consumption during USB data transfer. So, we decided to perform our own experiment.


We have used various combinations of host systems and mobiles.

Notebooks Operating System Apple MacBook Pro OS X 10.10.5 Dell Latitude E6320 Windows 7 64-bit Enterprise Edition

To which we’ve been connecting these mobile phones:

Mobile device Platform Samsung GT-i9300 (Galaxy S3) Android 4.4 LG Nexus 6X Android 6.0.1 Apple iPhone 4s iOS 9.2.1

The choice of mobiles was dictated by the fact that Android 6 mobiles behave themselves differently than smartphones on earlier versions of Android. They have a built-in protection from USB data transfer, enabling “charge-only” mode by default upon connection to a USB port. However, since we already knew from the previous research that a handshake, nonetheless, occurs in this setting, too, we wanted to check the energy consumption of phones during handshakes. We also wanted to discover the difference in behavior of mobiles based on different versions of Android and iOS.

Diagram of the experiment set-up in the MacBook Pro experiment

Experimental set-up in the Dell Latitude E6320 experiment

Our simple experiment, in essence, was to measure the current flowing through the wire that connects the system, which comprises a host, a connected mobile, and a power outlet. We designed this experiment in such a way, on one hand, to ensure the reproducibility of its results and, on the other hand, to avoid damaging the computer’s power adapter. Thus, we also tested the stability of the frequency and voltage of the alternating current and saw no dependence of these two parameters from the data exchange.

Since the multimeter provided us with RMS (root mean square) values of the alternating current within finite time intervals, the amount of consumed energy can be approximated by a sum of products of current IRMS average value of voltage URMS and time interval duration δt. We have used the RMS values of current in all our calculations instead of amplitude (I0 = IRMS *√2), because, by definition, the RMS value is equivalent to a value of DC current that dissipates the same amount of heat on the same resistive load.

Results Handshakes

In order to exclude the charging current’s influence on multimeter readings, the mobiles and laptops which we used as host computers, were fully charged. Furthermore, we used a Pure.Charger device, which allows us to turn the USB data lines on and off as desired. The sequence was the following: first we connected the Pure.Charger to the host computer’s USB port and then we introduced the mobile device to Pure.Charger’s output USB port. By doing so, we effectively separated the moment of connection to the USB port and the moment when data lines were enabled.

In the graph below you can see the consumption current dynamics (in mA) when a Nexus 5X was connected to a MacBook Pro host:

Here we see two distinct peaks of current, first when the phone is connected to a data line in “charge-only” mode, and second – when the MTP mode is enabled.

Current consumption dynamics for the connection of an unblocked Samsung S3 looks like this:

Here we see a single large consumption peak – because the phone is not blocked, it starts an MTP session right after it’s connected to the port.

The graph below we obtained with an iPhone 4S and a Latitude E6320 with the same settings:

The main consumption peak, due to the handshake between the Latitude E6320 and iPhone 4S, is preceded by a smaller spike, which corresponds to a handshake between the Latitude E6320 and Pure.Charger. As the amount of energy consumed during the handshake is proportional to the area below the curve, it can be seen that the amount of energy consumed due to the handshake of the host with Pure.Charger is significantly lower that the amount consumed due to the handshake with the iPhone 4S.

The experiment with the Latitude E6320 and iPhone 4S is the only one where Pure.Charger’s handshake is clearly seen – it is not distinctly observed in other experiments. The Pure.Charger’s consumption current, as obtained in the series of the experiments, does not exceed the idle current standard deviation for both the MacBook and the Latitude E6320.

The value of current fluctuations in the Latitude E6320 experiment (standard deviation was equal to 7-8 mA) was greater than current fluctuations in the MacBook experiment (standard deviation was equal to 4 mA). There are two reasons for this. Firstly, the Latitude E6320 was built using HDD and the MacBook Pro that we used was built using SSD. Secondly, in the corresponding experiment the Latitude E6320 was used both as a host and as a logging system.

Data transfer

In order to learn more about how much energy is required to send a unit of data over a USB connection, we had the hosts and the mobiles transfer files of a specified size to one another.

Fixed amount of data

The dynamics of the consumption current, in mA, for the Nexus 5X that was tasked with transferring 391 MB of data to the MacBook host, looked like this:

Here we observe the same two consumption peaks specific to an Android 6-based device, and an increase in the average consumption current during data transfer.

This is how the consumption current depends on time in an experiment where the MacBook Pro was reading 188 MB of data from Samsung S3:

Here we see a sharp single peak corresponding to a handshake with Samsung S3, a distinct start and finish of file transfer with increased consumption current, and a small spike in the current when the phone is disconnected, which is due to the system closing processes and windows which were active when the phone was connected.

We have carried out multiple similar experiments. As expected, the time interval elapsed for file transfer, was dependant on the file size – the larger the file, the longer it takes to send it through the USB channel.

Energy consumption dependence on the direction of data transfer

Does energy consumption depend on the direction of data transfer? We set up an experiment during which a group of files of the same size was sent to the host from the mobile, and vice versa, and measured the system’s consumption current. Because it’s impossible to send the files directly to an iOS-based mobile, this experiment was performed only with Android-based systems.

The left-hand graph shows the consumption current dynamics (in mA) when the Latitude E6320 is connected to the Samsung S3 and reads 808 MB of data. The graph on the right shows the current consumption when the Latitude E6320 sends the same amount of information to the Samsung S3. Despite the noise specific to the Latitude E6320 series of experiments, the moments of file transfer start and finish are seen clearly.
We carried out six similar experiments and came to the following conclusions:

  1. The average value of consumption current while sending data from the host to the mobile is lower, and this decrease is greater than the standard error.
  2. Meanwhile, the time elapsed for sending the file from a host to a mobile is longer than the time elapsed for receiving the same-sized file by a host from a mobile. This time interval increase is roughly the same as the decrease in average consumption current.

Taking into account that the voltage was the same, the energy consumption can be estimated as a product of voltage times average current and times the length of the time interval. The estimated values of energy consumption for data transfer from mobile to host and from host to mobile were effectively in the same confidence interval.

Energy consumption per unit of information

In order to approximate the dependence of consumed energy on the size of data we made two assumptions:

  1. The amount of energy required to transfer a unit of data depends only on the type of host and mobile.
  2. The amount of energy required to transfer a known amount of data is directly proportional to the size of data sent. This assumptions is probably not correct, because communication systems, and USB in particular, are optimized for sending data in bulk, thus the smaller the amount, the less energy is required to transfer it. However, there are accompanying computational processes that don’t go away. Therefore, it would be more accurate to approximate this dependence with a power function with fractional index. But the difference between linear approximation and such a power function would be significant for smaller amounts of data.

Under these assumptions, we have estimated that the most energy-efficient pair is the MacBook Pro connected with the Samsung S3 – they dissipate only (3.3±0.2)x10-8 Joules per bit, and the most power-hungry combination was the Latitude E6320 with the iPhone 4S, which dissipated (9.8±0.6)x10-8 Joules per bit.


The amount of energy required to transfer a unit of information through the USB channel is within the range of 3.1×10-8 to 1.4×10-7 Joules per bit. Remember the article we cited in the beginning? Their assessment (for transfer of Internet data) was 4×10-7 Joules per bit, which means that our assessment for USB connections is within the same order of magnitude.

Still, there are two more things to consider for further research. First, data transfer during handshakes is different from file transfer as it involves more computational processes and thus leads to greater consumption of system energy. Second, the dependence of energy consumption on the size of transferred data is presumably not quite linear, and for better accuracy should be approximated with a convex function. A better approximation requires more data points and more pairs of hosts and mobiles to be investigated.

Economy of scale

To sum it all up, I’d like to estimate the ratio of energy consumption caused by handshakes to the energy that is consumed while charging a mobile device. A typical charge on a 2 A current would last 20 to 40 minutes, which means that a mobile receives anywhere from 12 to 24 kJ of energy when charging. Therefore, blocking the handshakes that waste a few to dozens of Joules, allows for saving tenths to hundredths of a percent of this energy. A single user would not even notice this effect, but if all the folks living in New York used a Pure.Charger, they would save a whopping 33 Kilowatt-hours of electricity every day! To give you an idea of how much this is – Tesla electric cars can drive over 100 miles on this charge. This may not look like a big deal for a mega polis, but it’s a noticeable effect, isn’t it?

We will continue to research the physical characteristics of mobile devices during data exchange, both from a security perspective and in search of more data points. We welcome readers to reproduce this experiment themselves and report their findings!

This material uses experimental results submitted for publication in IEEE Transactions on Mobile Computing. The preprint is available here.