Malware RSS Feed

Industrial cybersecurity threat landscape

Malware Alerts - Mon, 07/11/2016 - 04:58

 Download ICS availability statistics (PDF version)

 Download ICS vulnerabilities statistics (PDF version)


Industrial control systems (ICS) surround us: they are used in electric, water and wastewater, oil and natural gas, transportation, chemical, pharmaceutical, pulp and paper, food and beverage, and discrete manufacturing (e.g., automotive, aerospace, and durable goods). Smart cities, smart houses and cars, medical equipment – all of that is driven by ICS.

Expansion of the Internet makes ICS easier prey to attackers. The number of ICS components available over the Internet increases every year. Taking into account that initially many ICS solutions and protocols were designed for isolated environments, such availability often provides a malicious user with multiple capabilities to cause impact to the infrastructure behind the ICS due to lack of security controls. Moreover, some components are vulnerable themselves. The first available information about vulnerabilities in ICS components is related to 1997, only two vulnerabilities were published that year. Since then the number of vulnerabilities significantly increased. Over the past five years this index has increased from 19 vulnerabilities in 2010 to 189 vulnerabilities in 2015.

Sophisticated attacks on ICS systems are not somewhat new anymore. It is worth remembering an incident in 2015 in Ivano-Frankivsk, Ukraine where around a half of houses were left without electricity because of a cyber-attack against the Prykarpattyaoblenergo power company, and it was only one of multiple victims of the BlackEnergy APT campaign.

Another notable incident, happened in 2015 and described in Verizon Data Breach Digest, is an attack on Kemuri Water Company’s ICS infrastructure, when intruders infiltrated a water utility’s control system and changed the levels of chemicals being used to treat tap water. The intrusion was performed through a vulnerable externally available system, that managed programmable logic controllers (PLCs) regulating valves and ducts that controlled the flow of water and chemicals used to treat it through the system.

Also in 2015 there were other ICS-related incidents, such as attacks on a steel mill in Germany and on the Frederic Chopin Airport in Warsaw.

In this research we provide an overview of the current situation with ICS security worldwide from the point of view of vulnerabilities, and vulnerable ICS components exposed to the Internet.

Analysis Approach

The research is focused on two areas: Vulnerabilities and ICS Availability over the Internet. Vulnerabilities information gathering was carried out based on open sources, such as Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) advisories, NVD/CVE, SCADA Strangelove, Siemens Product CERT and other information available online. Severity levels for the vulnerabilities were assessed based on a Common Vulnerability Scoring System (CVSS) of the versions 2 and 3. CVSS v2 was used to compare vulnerability statistics in the years 2014 and 2015, and it was also used for any vulnerabilities that didn’t have CVSS v3 score assigned.

In the second part of research results (ICS Availability over the Internet) we used a passive approach for analysis based on information from the Shodan search engine. To identify ICS systems in Shodan search we used a fingerprint knowledgebase, containing about 2000 records and allowing to identify product vendors and versions by banners.

Main Findings
  • The number of vulnerabilities in ICS components keeps growing. With increased attention to ICS security over the last several years, more and more information about vulnerabilities in these systems is becoming public. However, vulnerabilities themselves could be present in these products for years before they are revealed. In total, 189 vulnerabilities in ICS components were published in 2015, and most of them are critical (49%) or have medium severity (42%).
  • ICS vulnerabilities by year

  • Vulnerabilities are exploitable. For 26 of the vulnerabilities published in 2015, exploits are available. Besides, for many vulnerabilities (such as hard-coded credentials) an exploit code is not needed at all to obtain unauthorized access to the vulnerable system. Moreover, our ICS security assessment projects show that ICS are often considered by their owners as a “black box”, so default credentials in ICS componenets are often not changed and could be used to gain remote control over the system. The SCADAPASS project of the SCADA Strangelove team provides a representation of known default ICS credentials. Currently information on 134 ICS components of 50 vendors is available.
  • ICS vulnerabilities in 2015 by risk level (CVSS v.2 and CVSS v.3)

  • ICS vulnerabilities are widely diversified. New vulnerabilities were found in 2015 in the ICS components of different vendors (55 different manufacturers) and types (HMI, electric devices, SCADA, industrial network devices, PLCs and multiple others). The largest amount of vulnerabilities were found in Siemens, Schneider Electric and Hospira devices. Vulnerabilities in ICS components have a different nature. The most widespread types are buffer overflows (9% of all detected vulnerabilities), use of hard-coded credentials (7%) and cross-site scripting (7%).
  • Not all of the vulnerabilities found in 2015 are fixed. Patches and new firmware are available for 85% of the published vulnerabilities, the rest are not fixed or are only partially fixed for different reasons. Most of the unpatched vulnerabilities (14 out of 19) are of high level risk. These unpatched vulnerabilities pose significant risk to the owners of the corresponding systems, especially for those who, due to inappropriate network configuration management, have their vulnerable ICS systems exposed to the Internet. Examples include the 11,904 remotely available SMA Solar Sunny WebBox interfaces that are under risk of compromise though hard-coded passwords. Although for Sunny WebBox this number has significantly reduced since 2014 (when over 80 thousand available components were found), the amount is still high, and the unfixed hardcoded credentials issue (published in 2015) is now putting these systems under a much higher risk than was previously thought.
  • ICS patching

  • Numerous ICS components are available via the Internet. 220,668 ICS components were discovered by the Shodan search engine. They are located on 188,019 hosts in 170 countries. Most of the remotely available hosts with ICS components are located in the United States (30.5%) and Europe. Among European countries Germany has a leading position (13.9%) followed by Spain (5.9%). The available systems are of 133 different vendors. The most widespread ones are Tridium (11.1%), Sierra Wireless (8.1%), and Beck IPC (6.7%).
  • TOP 20 countries by ICS availability

  • Insecure protocols are widely used by remotely available ICS components. There is a number of protocols, which are open and insecure by design, such as HTTP, Niagara Fox, Telnet, EtherNet/IP, Modbus, BACnet, FTP, Omron FINS, Siemens S7 and many others. They are used on 172,338 different hosts, which corresponds to 91.6% of all the externally available ICS devices found. This provides an attacker with additional ways to compromise the devices by performing man-in-the-middle attacks.
  • TOP 15 protocols used by externally available ICS components

  • Multiple vulnerable ICS components are externally available. We found 13,033 vulnerabilities on 11,882 hosts (6.3% of all hosts with externally available components). The most widespread revealed vulnerabilities are Sunny WebBox Hard-Coded Credentials (CVE-2015-3964), and critical vulnerabilities CVE-2015-1015 and CVE-2015-0987 in Omron CJ2M PLC. Combining these results with statistics of usage of insecure protocols, we were able to estimate the total number of vulnerable ICS hosts as 172,982 (92%).
  • TOP 5 vulnerabilities on ICS components

  • Multiple industries are affected. We found that at least 17,042 ICS components on 13,698 different hosts in 104 countries likely belong to large companies, and availability of these components from the Internet is likely related with significant risks. Among owners we were able to identify 1,433 large organizations, including ones belonging to the following industries: electricity, aerospace, transportation (including airports), oil and gas, metallurgy, chemical, agriculture, automotive, utilities, drinks and food manufacturing, construction, liquid storage tanks, smart cities, and ICS vendors. There are also research and education entities, government institutions (including police), medical centers, financial organizations, resorts, hotels, museums, libraries, churches and multiple small businesses among identified owners of remotely available ICS. The number of vulnerable externally available ICS hosts, which likely belong to large organizations, is 12,483 (91.1%), where 453 hosts (3.3%), including hosts belonging to energy, transportation, gas, engineering and manufacturing organizations, drink and foods manufacturing, energy and transportation organizations, contain critical vulnerabilities.

ICS availability by vendor

The above results are only lower bound estimations, and real number of available ICS components associated with significant risks could be much higher.


Where protection is concerned, the isolation of critical environments can no longer be regarded as a sufficient security control for ICS. The business requirements of the 21st century often make it necessity to integrate ICS with external systems and networks. In addition, the capabilities, motivations and number of threat actors focusing on ICS environments are increasing. From infected hard drives or USB sticks, to unauthorized connections from ICS networks to the Internet through personnel smart phones or modems, and from infected distributive kits obtained from vendors, to a hired insider – all of these methods are available to highly-skilled intruders planning an attack on a physically and logically isolated ICS network.

Nowadays, ICS owners should be aware of modern vulnerabilities and threats, and actively improve the security of their ICS environments based on this knowledge. Here, active vendor support is crucial for the prompt identification and remediation of vulnerabilities in ICS products, as well as for sharing workarounds to protect systems before patches are released.

The specifics of ICS – that its cybersecurity is closely tied with physical safety – often receives an attitude opposite to the demandable treatment in such conditions. Small and medium businesses, as well as individuals, completely rely on vendors when it comes to security of the Internet of Things. The consumers don’t go beyond simple basic steps from device manuals, thus obtaining ready-to-work and easily accessible, but also vulnerable devices. On the contrary, in the enterprise area, companies understand the high risks, which are related with incorrect configuration of ICS environment. However, because of that system owners often consider ICS devices as “black-boxes”, and have a dread to make changes in the environment, including cybersecurity enhancement.

The findings of this research are an additional reminding that the “Security through Obscurity” principle cannot serve as a good basis to achieve effective protection from modern attacks, and that industrial control systems security should not be treated superficially in favor of safety, especially because the security and safety in this area are inextricably connected.


SANS Tip of the Day - Mon, 07/11/2016 - 01:00
Make sure you have anti-virus software installed on your computer and that it is automatically updating. However, keep in mind that no anti-virus can catch all malware; your computer can still be infected. That is why it's so important you use common sense and be wary of any messages that seem odd or suspicious.

The Dropping Elephant actor

Malware Alerts - Fri, 07/08/2016 - 01:57

Dropping Elephant (also known as “Chinastrats”) is a relatively new actor targeting a variety of high profile diplomatic and economic targets using a custom set of attack tools. Its victims are all involved with China’s foreign relations in some way, and are generally caught through spear-phishing or watering hole attacks.

Overall, the activities of this actor show that low investment and ready-made offensive toolsets can be very effective when combined with high quality social engineering. We have seen more such open source toolset dependency with meterpreter and BeEF, and expect to see this trend continue.

The Attack Method: Infection Vector

Dropping Elephant uses two main infection vectors that share a common, and fairly elaborately maintained, social engineering theme – foreign relations with China.

The first approach involves spear-phishing targets using a document with remote content. As soon as the user opens the document, a “ping” request is sent to the attackers’ server. At this point, the attackers know the user has opened the document and send another spear-phishing email, this time containing an MS Word document with an embedded executable. The Word document usually exploits CVE-2012-0158. Sometimes the attackers send an MS PowerPoint document instead, which exploits CVE-2014-6352.

Once the payload is executed, an UPX packed AutoIT executable is dropped. Upon execution, this downloads additional components from the attackers’ servers. Then the stealing of documents and data begins.

The second approach involves capturing victims through watering hole attacks. The actor created a website that downloads genuine news articles from other websites. If a website visitor wants to view the whole article they would need to download a PowerPoint document. This reveals the rest of the article, but also asks the visitor to download a malicious artifact.

The two main infection vectors are supported by other approaches. Sometimes, the attackers email out links to their watering hole websites. They also maintain Google+, Facebook and twitter accounts to develop relevant SEO and to reach out to wider targets. Occasionally, these links get retweeted, indiscriminately bringing more potential victims to their watering holes.

The Attack Tools 1. Malware Analysis

The backdoor is usually UPX packed but still quite large in size. The reason for this is that most of the file comprises meaningless overlay data, since the file is an automatically generated AutoIT executable with an AutoIT3 script embedded inside. Once started, it downloads additional malware from the C2 and also uploads some basic system information, stealing, among other things, the user’s Google Chrome credentials. The backdoor also pings the C2 server at regular intervals. A good security analyst can spot this while analyzing firewall log files and thereby find out that something suspicious might be going on in the network.

Generally speaking, backdoors download additional malware in the form of encrypted or packed executables/libraries. But, in the case of Dropping Elephant, the backdoor downloads encoded blobs that are then decoded to powershell command line “scripts”. These scripts are run and, in turn download the additional malware.

One of the more interesting malware samples downloaded is the file-stealer module. When this file-stealer is executed, it makes another callback to the C2 server, downloading and executing yet another malware sample. It repeatedly attempts to iterate through directories and to collect files with the following extensions: doc, docx, ppt, pptx, pps, ppsx, xls, xlsx, and pdf. These files are then uploaded to the C2 server.

Also interesting are the resilient communications used by this group. Much like the known actors Miniduke or CommentCrew, it hides base64 encoded and encrypted control server locations in comments on legitimate web sites. However, unlike the previous actors, the encrypted data provides information about the next hop, or the true C2 for the backdoor, instead of initial commands.

2. C2 Analysis

In many cases it was very difficult to get a good overview of the campaign and to find out how successful it is. By combining KSN data with partner-provided C2 server data, we were able to obtain a much fuller picture of the incident.

We examined connections and attack logins to this particular C2. As it turned out, the attackers often logged in via a VPN, but sometimes via IPs belonging to an ordinary ISP in India. We then looked at the time the attackers were active, of which you can find an image below.

Victim Profile and Geography

We also wanted to get a better idea of the geolocation of most visitors. Analysis of the image provided access counts and times, along with the IP of the visiting system.

Noteworthy are the many IPs located in China. This focus on China-related foreign relations was apparent from the ongoing social engineering themes that were constant throughout the attacks. The concentration of visits from CN (People’s Republic of China) could be for a variety of reasons – diplomatic staff are visiting these sites from their CN offices, CN academics and analysts are very interested in researching what they believe to be CN-focused think tanks, or some of the IPs are unknown and not self-identifying as bots or scrapers. Regardless, because we were able to determine that multiple targets are diplomatic and governmental entities, these foreign relations efforts are likely to represent the main interest of the attackers.


Campaigns do not always need to be technically advanced to be successful. In this case, a small group reusing exploit code, some powershell-based malware and mostly social engineering has been able to steal sensitive documents and data from victims since at least November 2015.

Our analysis of the C2 server confirmed the high profile of most victims, mainly based in the Asian region and specially focused on Chinese interests. Actually, some hints suggest the group has been successful enough to have recently expanded its operations, perhaps after proving its effectiveness and the value of the data stolen.

This is quite worrying, especially given the fact that no 0 days or advanced techniques were used against such high profile targets. Simply applying software patches will prevent attacks based on old exploits, as well as training in the most basic social engineering attacks.

However, it should be noted that in this case Microsoft´s patch for exploit CVE-2014-1761 just warns the user not to allow the execution of the suspicious file.

Dropping Elephant artifacts are detected by Kaspersky Lab products as:

As usual Kaspersky Lab actively collaborates with CERTs and LEAs to notify victims and help to mitigate the threat. If you need more information about this actor, please contact

More information on how Kaspersky Lab technologies protect against such cyberespionage attacks is available on Kaspersky Business blog.

Indicators of Compromise Backdoors


Exploit documents

d69348794e85ddea6a5f68b85f9bf47b 10_gay_celebs.doc
9f9824e9a4d7d3073aebbcc781869660 1111_v1.doc
d1c864ae8770ae43a0e59a31c0788dc2 13_Five_Year_Plan_2016-20-1.pps
9a0534772ac23ff64e3c85b18fbec596 2015nianshijiexiaoxuanshou.doc
a46d44e227b49d2075730610cfec0b2e 7GeopoliticalConsequencetoAnticipateinAsiainEarly2016_1.doc
79afb3f44172447015578b8064c1dda0 7GeopoliticalConsequencetoAnticipateinAsiainEarly2016_2.doc
6abf60e9e2f6e3fa4c8020e1b2ef2867 ABiggerBolderChinain2016_1.doc
89963d5aac8441b0febbe5d5a0ab7629 ABiggerBolderChinain2016_2.doc
d79e1d6302aabbdf083ba89a7c2f34fc aeropower.pps
90af176bfdf248d2899b49316458e4b6 australia_fonops_1.pps
24c722f3d0770ede82fa3d6b550098b3 australia_fonops_2.pps
08a116efce7d947257ce94fc8f3e276e aviation_1.pps
0ae8f01b9ba0394f5e68536574076aa1 aviation_2.pps
0d1bdb45bac3b09e28e4f0cb09c97194 beauty3.pps
d807fb3cb1a0687e152d288171ab9b59 beauty6.pps
f017c65c7b5d14df11c5e0e4f0406562 CHINA_FEAR_US_3.pps
3cd8e3e80a106b0590a7b5eedddf4715 CHINA_FEAR_US_6.pps
a1940b31af27139a13dff852cb012a22 ChinainSyria.doc
e7ba5c209635607b2b0e38a00a822953 chinamilstrat1.doc
d273f090b96eca7c93387a03d9527d9b chinamilstrat2.doc
17d5acf49a4d65a4aacc362576dbaa12 chinamilstrength.pps
3c68ca564595e108920a0f105728fded China_Response_NKorea_Nuclear_Test1.pps
8c21aee21b6bfa12ecf6070a4532655a China_Response_NKorea_Nuclear_Test2.pps
533ce967d09189d27f38fe6ed4711099 chinascyberarmy2015_1.pps
9c9e5d09699821c53d68e957044ec6e8 chinascyberarmy2015_2.pps
c4f5d6ed36c3d51cb1b31f20922ce880 ChinasMilitaryIntelligenceSystemisChanging_1.doc
1fb7eece41b964517d5224b57073c5d4 ChinasMilitaryIntelligenceSystemisChanging_2.doc
1e620679c90563d46aa349e991d2e0f2 CHINA’S_PUZZLING_DEFENSE_AGREEMENT_WITH_AUSTRALIA_1.doc
a0177d2fd49d835244028e98449c77a5 CHINA’S_PUZZLING_DEFENSE_AGREEMENT_WITH_AUSTRALIA_1.pps
1e620679c90563d46aa349e991d2e0f2 CHINA’S_PUZZLING_DEFENSE_AGREEMENT_WITH_AUSTRALIA_2.doc
70c5267c56ded521c6f674a6a6649f05 CHINA’S_PUZZLING_DEFENSE_AGREEMENT_WITH_AUSTRALIA_2.pps
a1940b31af27139a13dff852cb012a22 ChinatoReceive_S-400_Missiles.doc
77ff734bc92e853b92595ddf999ee1ec China_two_child_policy_will_underwhelm1.doc
8c875542def907312fd92d10746c230c China_two_child_policy_will_underwhelm1.pps
e98b1ed80ba3a3b6b0809f04536e9753 ChinaUS_1.pps
36581da1d10ba6382a63e7046c21dd8d ChinaUS_2.pps
9a7e499d7abfcbe7fb2a78cf1d7a2f10 chinesemilstrat_1.pps
40ace1c9394c95d7e9e1e80f24bd1a73 chinesemilstrat_2.pps
71d59036f84aba8e60aa8785e3883372 cppcc_1.pps
04aff7c333055188219e290e58313d78 cppcc_2.pps
dffe28c9c4dc9e2e865e3237f4bc38c4 Dev_Kumar_Sunuwar.doc
ae27773e49fea122e3f8ce7a27e6c555 election.pps
86edf4fab125d8ccba85138f43b24def enggmarvels_1.pps
a8022594e81c74b22abca772eb89657c enggmarvels_2.pps
bc08d1bddf72369adceffbfc36f848df fengnew33.pps
2c70e1f152e2cb42bb29aadb66ece2ec fengnew36.pps
3a2be243b0c78e8689b34e2415d5e479 fengnew63.pps
2158cb891a8ecbaaa70a641a6529b787 fengnew66.pps
a1940b31af27139a13dff852cb012a22 final.doc
a1940b31af27139a13dff852cb012a22 FinancialCrisisChina.doc
884f76542f3972f473376c943daeaf8f futuredrones_1.pps
098c74c23ed73ac7bf7581fec2eb088d futuredrones_2.pps
915e5eefd145c59677a2a9eded97d114 gaokaonewreforms_1.doc
57377233f2a946d150115ad23bbaf5e6 gaokaonewschedule_1.pps
1c5b468489cf927c1d969484ddbdd8ea gaokaonewschedule_2.pps
fa2f8ec0ab22f0461e860394c6b06a68 harbin_1.pps
9a0534772ac23ff64e3c85b18fbec596 Heart_Valve_Replacement.doc
4ea4142bab2b90e5779df19616f7d8ca Implication_China_mil_reforms_1.doc
8a350d3f6fb359377d8939e1a2e033f3 Implication_China_mil_reforms_1.pps
f5e121671384fbd43534b8515c9e6940 ISIS_Bet_Part1.doc
3a83e09f1b751dc08f4b719ed51c3fbc ISIS_Bet_Part2.doc
8a1a10dcc6e2ac6b40a86d6ed20cf1bd japan_pivot_1.pps
72c05100da6b6bcbf3f96fee5cf67c3f japan_pivot_2.pps
ebe8efbad7f01b76465afaf474589c2f jtopcentrecomn.pps
165ae88945852a37fca8ec5224e35188 korea1.pps
38e71afcdd6236ac3ad24bda393a81c6 militarizationofsouthchinasea_1.pps
61f812a1924e6d5b4307313e20cd09d1 militarizationofsouthchinasea_2.pps
4595dbaeec06e3f9b466d618b4da767e MilitaryReforms1.pps
1de10c5bc704d3eaf4f0cfa5ddd63f2d MilitaryReforms2.pps
ce1426ffe9ad4439795d269ddcf57c87 MilReform_1.doc
1e620679c90563d46aa349e991d2e0f2 MilReform_2.doc
8d2f4e691f2e318f7162a3a5d397b29c MilReforms_1.pps
631d44688303be28a1b825aa1c9f3202 MilReforms_2.pps
fe78c037844ad08a9a79c85f46e68a67 my_lovely_pics_3.pps
d5a976cc714651711c8f067dd5e00709 my_lovely_pics_6.pps
657e9333a052f593b7c51c58917a1b1f my_photos_3.pps
e08bbed0aa4b21ae921d4dc5350789c7 my_photos_6.pps
141a8b306af8087df4feee15f571eb59 nail_art_3.pps
122d7dff33174e532063a16ae526208d nail_art_6.pps
d049a6f9e527a72a4b917eec1acbd6f9 netflix1.doc
09a478efd8c5aeef3a5395e3988f5059 netflix1.pps
d791f8d9495d5d5df0cedb8b27fb3b49 netflix2.doc
e7b4511cba3bba6983c43c9f9014a49d netflix2.pps
d01be8c3c027f9d6f0d93542dfe7ca97 nianshijiexiaoxuanshou2015.doc
040712ba00b32cc19e1938e14e732f59 North_Korea_Nuclear_Test_1.doc
3b0ca7dafb94333234e4f1330a1699da North_Korea_Nuclear_Test_2.doc
1e620679c90563d46aa349e991d2e0f2 Obama_Gift_China_1.doc
6f327b93279f3ce39f4fbe7a610c3cd2 Obama_Gift_China_1.pps
1e620679c90563d46aa349e991d2e0f2 Obama_Gift_China_2.doc
58179b5cf455e2bcac396c697cd43050 Obama_Gift_China_2.pps
fa94f2843639f7afec3c06799a8d222e PAK_CHINA_NAVAL_EXERCISEn.doc
4d2bde1b3985d1e1088801d92d1d6ca9 pension_1.pps
9a0534772ac23ff64e3c85b18fbec596 Reconciliation_China’s_PLAN.doc
2c9b4d460e846d5814c2691ae4591c4f Stewardess1.doc
dab037a9e02978bcd275ddaa15dab01d stewardess1.pps
007c9c29786d0af81caf437fe626c6fe Stewardess2.doc
8aae16b5e64445703d939bc7923ae7b7 stewardess2.pps
036a45983df8f81bf1875097fc026b04 syria_china.pps
a8b9a32723452d27257924a737ec1bed TaiwanDiplomaticAccess_1.pps
f16ee3123d5eb21c053ac95e7cd4f203 TaiwanDiplomaticAccess_2.pps
71ce64fee9cd323828a44e9228d2736b tibetculture_1.pps
b5e5e428b31a8affe48fdf6b8a253dc6 tibetculture_2.pps
d64efa0b8c091b8dbed3635c2b711431 underestimatingUS_1.pps
543fe62829b7b9435a247487cd2a9672 underestimatingUS_2.pps
807796263fd236a041f3633ac578140e UruguayJan-Jun_1o.pps
98e7dc26531469e6b968cb422371601a uruguayjan-jun_1.pps
7eb1b6fefe7c5f86dcc914056928a17b UruguayJan-Jun_2o.pps
7660c6189c928919b0776713d2755db2 uruguayjan-jun_2.pps
7c4c866cf78be30229b75a3301345f44 UruguayJul-Dec_1o.pps
a4fcf3a441865ae17f2c80ff7c28543d uruguayjul-dec_1.pps
dba585f7d5fc51566c663bd738de2c33 UruguayJul-Dec_2o.pps
f7905a7bd6483a12ab36071363b012c3 uruguayjul-dec_2.pps
409e3368af2add71265d2811aa9d6817 US_China.doc
5a89f11f4bb3b5637c731e206f807ff7 us_srilanka_relations_1.pps
7f50d3f4eabffe7225a2d5f0c91009c8 us_srilanka_relations_2.pps
3d01d2a42450064c55574d853c086f9a WILL_ISIS_INFECT_BANGLADESH.doc
1538a412fd4035954237c0b4c135fcba WILL_ISIS_INFECT_BANGLADESH.pps
eb0b18ecaa6f40e48970b08f3a3e6803 zodiac_1.pps
da29f5eeb39332a850f04be2906315c1 zodiac_2.pps

Domains and IPs


C2 redirectors (with obfuscated comments)

VDI: Non-virtual problems of virtual desktop security, and how to solve them for real

Malware Alerts - Thu, 07/07/2016 - 06:55


Virtualization marches victoriously across the globe, adding to its list of champions not only individual IT-specialists and businesses, but even whole sections of the IT industry. In fact, it’s barely possible to find a data center with only physical servers on board: both electricity and physical space are far too expensive nowadays to be used so inefficiently.

Meanwhile, the possibility of hosting multiple servers on a single physical machine is just one benefit among all those offered by virtualization.

Second only to servers, the most important application of today’s virtualization technologies is probably Virtual Desktop Infrastructure, or VDI. While using the same concept of multiple computers hosted inside a single physical ‘body’, its purpose is entirely different from server virtualization: to substitute a heterogeneous and cumbersome ‘zoo’ of physical desktops with homogenous and easily controlled virtual environment.

As opposed to familiar – and age-old – Terminal Services infrastructure, offering shared access to the same machine running a single instance of an operating system, VDI is about ‘genuine’ virtualization. Every single virtualized workstation has its own set of virtual hardware, OS and applications – and its own range of potential security issues. There tends to be a much higher probability, too, of encountering security issues with VDI than with virtualized servers. This is especially true in scenarios which include access to the ‘Big Internet’, with its landscape of threats and hordes of marauding cyber-predators, always hungry for other people’s data and money. And God help you, if you buy into the myth about virtual environments being inherently more secure than physical ones! The exact opposite is true: not only they are similar in terms of threat levels; virtual environments possess some specifics that actually make the task of securing them even more complex.

This is what we are going to talk about here: about VDI myths, specifics – and how to provide proper security for corporate VDI, without compromising any of its many benefits.

VDI: Pros and Cons The Pros

Before plunging deep into problems associated with VDI, it might be useful to remind ourselves of the benefits that have earned the technology the undying love of both sysadmins and ITSec specialists.

  • VDI is effectively agnostic of the end-user’s hardware and software. The only requirement for any client device, be it a regular PC, a smartphone or a thin station, is the ability to run a client application (in some cases, even a simple web browser will do).
  • VDI offers a considerably higher level of data security. With all the valuable information stored deep inside the corporate infrastructure or in a datacenter, many data loss scenarios, like device theft or physical loss, are ruled out.
  • VDI environments are highly flexible in management terms: every virtualized workstation and application can be deployed and controlled with an ease and speed that’s unattainable for purely physical infrastructures. With finely tuned working practices, it may not even be necessary to solve any problems associated with a given virtual machine: just killing the VM and spawning it back from the template can be enough. All user data can then be re-accessed from centralized storage once the user logs back in.

This list of VDI benefits is clearly incomplete. But even these key points are enough for some businesses requiring high mobility accompanied by strong data security to embrace the concept with eagerness. Typical examples are healthcare, insurance and, in some regions, banking; business processes taking place in these industries are highly regulated and easily formalized, which greatly simplifies the task of VDI implementation.

The Cons

Unfortunately, no solution consists entirely of benefits – and VDI has its range of nuances and limitations to be mindful of.

  • VDI is highly sensitive to resource consumption. Virtual environments are designed so that users can perform tasks in a way that’s very similar to using regular PCs. But, even when a limited number of software titles are used for a limited number of tasks, some can not only be resource-hungry, but can have a considerable adverse impact on VDI performance in particular. Few things are more demotivating to a workforce than system lags and general unresponsiveness; as well as unnerving and irritating people, this can easily kill off all the efficiency gains delivered by VDI deployment. So it’s necessary to consider and to constantly monitor all the influences on system responsiveness – including the impact of security solutions.
  • VDI works better with formalized business processes. VDI is most easily justified when business processes are predictable, and all the applications used are known. If this is not the case, resource consumption and overall performance calculations can suddenly prove misleading or just plain wrong. The threat to corporate security posed by the unrestricted use of unknown applications, or course, presents a threat to corporate security, as well as compromising the accuracy of performance predictions.
  • VDI presents complex requirements for deployed security solutions. As opposed to attacks on data-storing servers and similar scenarios where the main target is remotely accessible data, virtualized workstations are subject to practically the same spectrum of threats as those targeting physical machines. These threats can include, for example, ‘bodiless’ malware using exploits to inject malicious code into legitimate processes and running entirely in the system’s volatile memory. Unfortunately, the majority of well-known specialized solutions claiming to cater for the specific requirements of virtualized environments offer protection at file system level only, which is far from adequate for VDI defense.

Of course, installing a security solution designed for physical desktops, perhaps modified to be ‘virtualization-friendly’, is an option. But this may well result in considerable increases in resource consumption, drastically reducing VDI efficiency. These solutions involve each virtual machine (VM) carrying its own set of engines and databases, each updating independently from its neighbors. In a worst case scenario, a solution’s failure to demonstrate sufficient ‘virtualization awareness’, can result in ‘activity storms’, where multiple simultaneous updates or scanning processes create an avalanche of increased resource consumption, bringing the entire host to a grinding halt.

Myths and Threats

Despite virtual desktops being very similar to their physical counterparts in terms of functionality, the misconception that they are less susceptible to infection is quite widespread amongst users and even IT professionals. Some of the arguments used may look like these:

  • Malware itself is afraid of virtual machines, suspecting them of being sandbox systems or researchers’ machines. So, when the malware detects that it’s being launched in a VM, it won’t activate.
  • In a properly configured VDI, the VM itself is of no value. If an infection strikes, it’s just a matter of killing off the infected machine, with no need to bother about the malware itself.

Let’s see what stands behind these assertions, and how safe it is to base your approach to VDI security on them.

VM as Malware’s Scarecrow

This argument is based on something that’s actually quite true: many malware specimens do check for signs that they’re being launched inside a VM. But what happens next is not so predictable. Malware creators are keenly aware that these VMs are usually NOT sandboxes and can contain valuable data – or can serve as entry points to entire IT networks. So they’re rapidly learning to tell sandboxes from less sophisticated VMs. For this, an extensive range of indicators can be used: previously investigated IP addresses of researchers’ systems, typical user and computer names, unnecessary system components missing or removed to reduce resource usage – and so on. There are also more advanced tricks and indicators to detect sandboxes, such as leaving some kind of token in the file system or repeated communications with C&C throughout the whole attack cycle (which won’t happen during sandboxing) etc. And there are also directly controlled targeted attacks, during which the command for proceeding (or withdrawing) is issued by living people, based on acquired intelligence.

The bottom line is this: some malware, and only some, may refuse to start in a VM. It would be extremely foolish to rely on this when building a security system for corporate VDI (which is even more susceptible to infection than server VMs).

No machine – no infection?

The main flaw in this argument lies in the perception of the infected machine as an isolated instance. Any infection can involve multiple VMs residing in the same network segment: if just one contracts malware, especially given the lightning-fast speed of a virtualized network, the contagion can spread like wildfire. It doesn’t matter if the original infected machine is killed – the process of cross-infection within a network segment with sufficient vulnerable nodes can theoretically go on forever. Or, more precisely, it can go on until the moment when the whole network segment shuts down entirely.

And another thing. With the initial infected machine consigned to oblivion, traces of the initial infection – all too precious for restoring a full picture of the attack during investigations – will be lost forever.

It’s also worth bearing in mind that some more advanced malware specimens can be remarkably adept at evading detection. Specialized security solutions working only at file system level, without the capability to watch over processes in memory, can give the malware plenty of time to do its job (e.g. syphoning away the data it has found) before the VM is deleted.

Obviously, if the infection is spotted after any malicious files may have been dropped into the file system, mercilessly killing off the affected VM is no guarantee that you have stopped the infection in its tracks.

The Boundless Sea of Threats

We have said that virtual desktops are susceptible to almost the same spectrum of threats as are physical machines. But what about specialized attacks, targeting the specific vulnerabilities of virtualized environments?

Well, there is no shortage of Proof-of-Concept demonstrations, as shown during security conferences and described on the internet. Potentially, such malware could do considerable harm, but… there are as yet no officially registered cases of such attacks being spotted in the wild. Still, there’s no reason to be over-optimistic. The most important driver to innovation in any area – including the creation of malware – is the existence of an obvious demand. Once the penetration rate of virtualized assets reaches a critical point, the in-lab theoretical threat could become a reality in no time. And here we’re talking about the more common threats; if there’s a requirement to attack a particular VDI in order to get to a particularly valuable piece of data (and the money to sponsor such a complex attack)… well, any kind of technology can be put to use, including fully customized designs that are completely unknown to the general public.

Even without the attack scenarios we anticipate in the immediate future, there is enough malware right now to provide VDI owners with the same problems that physical IT network owners already experience.

VDI Defense: Strategy and Tactics

Protecting VDIs is mandatory, and no mythical inherent resilience offers a legitimate defense against the existing threat landscape. So, how do we approach this task appropriately – and what stratagems can be used to best preserve all the beneficial effects of VDI deployment?

Configure Safely!

As we all know, the most dangerous vulnerability in any system is people. And we’re not only talking about careless office staff, mindlessly clicking on links and opening files received from strangers. This also applies to those equally careless IT specialists who configure their systems in ways that leave gaps for intruders to abuse.

So, what screws can be tightened to make the conditions as uncomfortable as possible for any attacker? Here are several examples which, theoretically, are applicable to both physical and virtualized networks.

  • Forbid any type of local authorization using domain policies. This can be especially useful for ‘disposable’ VMs, which are created and deleted on demand: the task of fixing a faulty machine, which could require a local login procedure, is not a viable option.
  • Whenever the business process allows this, reduce the user’s capability to run unsolicited programs to a minimum, perhaps going as far as deploying a Default Deny scenario. Given the known specifics of particular industries where VDI technology is most popular (like healthcare or insurance), the implementation of such a scenario can be undertaken without much hassle.
  • Rule out the use of Java and other command interpreters, including Powershell and even CMD.EXE, if business processes don’t explicitly rely on them. Java remains one of the most exploited components of any system, and script chains are gaining in popularity as a ‘legit’ way of circumventing detection and even application control mechanisms.
  • If the network configuration permits, use Private VLANs to isolate VMs from one another. In the majority of business scenarios, there’s no need for VMs to see one another on the network: they only need access to particular servers and network services – and to the internet if required. Such a configuration can considerably reduce the possibility of infection spreading. Though it’s worth bearing in mind that, in some cases, this would require the physical switchers to support PVLANs as well. But even then, as part of a Software-Defined Networks paradigm, there are virtual switches which prevent the flooding of physical switches without PVLAN support residing in the same IT network.

Private VLANs provide a simple way of selectively isolating VMs without exhausting IP subnets.
Source: VMware

Multi-layered protection

Taking into account the rapidly changing threat landscape, VDI protection should not be in any way inferior to defenses used for regular machines, especially if work undertaken includes accessing the big internet.

This means that, besides traditional signature-based protection or even advanced file-level protection based on heuristic algorithms, any solution should be armed with behavioral detection technologies and some means of exploit mitigation. And this can only be considered a bare minimum; ideally, the solution should possess additional proactive security layers such as application control, web control and device control.

The Conventional Approach

This can readily be achieved by installing regular security solutions using full-weight agents, initially designed for the protection of physical workstations. However, as discussed earlier, even if adjustments have been made to cope with specific aspects of virtual environments, the issue of excessive resource consumption requires a fundamentally different approach.

The Agentless Approach

One such approach leverages VMware’s vShield (and now NSX) technology, and so can only be adopted for VMware based environments. The ‘Agentless’ approach conducts all security activity in a single Security Virtual Machine (or SVM) on the virtual host, using VMware’s own technologies to communicate with and protect the individual VMs.

With signature updates and scanning engines held on just one SVM per host, instead of on every VM that the host is servicing, the resource savings compared with full-agent protection, in terms of both space and processing power, are considerable. And with just one SVM being updated, instead of all those individual machines, traffic is drastically reduced and ‘AV storms’, where lots of machines all try to update or perform malware scanning simultaneously, are eliminated.

For IT environments with no direct external exposure, particularly where foreign agents are not permitted onto clients’ machines – in a data centers for example – the agentless approach is an excellent solution. But, for VDI environments, such as VMware’s own Horizon, where individual machines are so much more exposed, this approach is definitely not sufficient in terms of security. This is primarily because an agentless approach does not allow the security solution any direct access to or control of processes in the individual machine’s memory.

The Lightweight Agent Approach

But there are specialized solutions providing high levels of security AND also operating as an organic element of the virtualized infrastructure, without duplication and resource wastage. The answer lies in solutions using lightweight agents.

Like agentless solutions, this approach also employs a dedicated ‘Security Virtual Machine’ (SVM), which does away with duplicated copies of scanning engines and databases residing on every single protected VM. Instead of relying on the vShield or NSX technology layer, however, this approach employs lightweight program agents, so that the solution can not only reach into the individual VMs’ systems on behalf of the SVM, but can also control processes in the machines’ memory, allowing for behavioral detection by other advanced technologies. And, of course, this approach is not tied to VMware technology, but can be applied to other platforms, including Citrix, Microsoft and KVM.

Solutions built using this principle also allow for the provision of additional security layers.

For example, in our Kaspersky Security for Virtualization | Light Agent, the following technologies are implemented:

  • Application Control (powered by cloud-based Dynamic Whitelisting)
  • Web Control (with cloud-supported Web Resource Categories)
  • Device Control
  • Network Attack Blocker (a network IDS/IPS protecting from network-based attacks and exploits)
  • HIPS (Host-Based Intrusion Prevention System)
  • Firewall (working on multiple OSI levels including Application)
  • Anti-phishing (backed by cloud-based reputational service and autonomous heuristics)

(More details about Kaspersky Security for Virtualization | Light Agent can be found here.)

All these protective layers provide much greater levels of security in defense of endpoints which, virtualized or not, remain the primary targets for attackers. Of course, every further security layer requires additional resources, but, with the majority of resource-heavy processes being relocated to the SVM, the deployed lightweight agents can easily remain quite slim.

Such architectures also ensure higher fault tolerance. Should an SVM become unavailable for a period of time, additional security layers won’t leave the machines completely unprotected. In addition, the system event data obtained can be stored locally for later analysis after re-establishing connection with the SVM – or being temporarily rerouted to another SVM on the same network.

Such solutions are initially designed to be fully aware of all virtualization’s unique requirements – and the specifics of VDI in particular, including mechanisms like machine migration or Linked Clones. Properly designed lightweight agents can also be easily embedded into VM templates, allowing instant protection immediately after machine activation.

All these mechanisms and their outcomes and benefits have been tested, in the case of Kaspersky Security for Virtualization | Light Agent, with popular VDI systems including VMware Horizon and Citrix XenDesktop in ‘real life’ conditions.

Heterogeneous environments

Since the connection between the agents and the SVM doesn’t require any platform-dependent intermediate layers, it’s possible not only to protect different virtualization platforms with ease, but also to cover heterogeneous environments with a single solution. This removes the necessity of having different management consoles for each platform solution, and considerably simplifies the management process for IT security specialists, saving time and reducing the probability of human error.


The global transition into virtualized space is still ongoing, and the number of VDI scenarios is growing every day. Even complex, resource-hungry tasks like graphic processing or software development, which were only recently being described as ‘future tech’, are a current reality. Unfortunately, it’s often impossible to formalize complex business processes using strict policies – so there are always ‘soft spots’ in any given system. These soft spots in virtual infrastructure need to be hardened using specialized security solutions combining both traditional and innovative, proactive protection methods. This combination is most commonly found in solutions using lightweight agents – which, given the existing threat model, become a natural choice for VDI protection.

An increase of sophisticated phishing attacks in Sweden

Malware Alerts - 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

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

Mobile Apps

SANS Tip of the Day - Wed, 07/06/2016 - 01:00
Only install mobile apps from trusted places, and always double-check the privacy settings to ensure you are not giving away too much information.