Malware RSS Feed
Ransomware’s popularity has attracted the attention of cybercriminal gangs; they use these malicious programs in targeted attacks on large organizations in order to steal money. In late 2016, we detected an increase in the number of attacks, the main goal of which was to launch an encryptor on an organization’s network nodes and servers. This is due to the fact that organizing such attacks is simple, while their profitability is high:
- The cost of developing a ransom program is significantly lower compared to other types of malicious software.
- These programs entail a clear monetization model.
- There is a wide range of potential victims.
Today, an attacker (or a group) can easily create their own encryptor without making any special effort. A vivid example is the Mamba encryptor based on DiskCryptor, an open source software. Some cybercriminal groups do not even take the trouble of involving programmers; instead, they use this legal utility “out of the box.”
The model of attack looks like this:
- Search for an organization that has an unprotected server with RDP access.
- Guess the password (or buy access on the black market).
- Encrypt a node or server manually.
Notification about encrypting the organization’s server
The cost to organize such an attack is minimal, while the profit could reach thousands of dollars. Some partners of well-known encryptors resort to the same scheme. The only difference is the fact that, in order to encrypt the files, they use a version of a ransom program purchased from the group’s developer.
However, true professionals are also active on the playing field. They carefully select targets (major companies with a large number of network nodes), and organize attacks that can last weeks and go through several stages:
- Searching for a victim
- Studying the possibility of penetration
- Penetrating the organization’s network by using exploits for popular software or Trojans on the infected network nodes
- Gaining a foothold on the network and researching its topology
- Acquiring the necessary rights to install the encryptor on all the organization’s nodes/servers
- Installing the encryptor
Recently, we have written about one of these types of ransomware, PetrWrap, on our blog.
The screen of a machine infected with PetrWrap
Of special note is the software arsenal of a few groups that is used to penetrate and anchor in an organization’s network. For example, one of the groups used open source exploits for the server software that was being used on the server of the victim organization. Once the attackers had exploited this vulnerability, they installed an open sourced RAT tool, called PUPY, on the system.
Pupy RAT description
Once they had gained a foothold in the victim network, the attackers used a Mimikatz tool to acquire the necessary access rights, and then installed the encryptor on the network using PsExec.
Considering the above, we can conclude that the scenario of ransomware infection in a target attack differs significantly from the usual infection scenario (malicious email attachments, drive-by-attacks, etc.). To ensure comprehensive security of an organization’s network, it is necessary to audit the software installed on all nodes and servers of the network. If any outdated software is discovered, then it should be updated immediately. Additionally, network administrators should ensure all types of remote access are reliably protected.
Of special note is the fact that, in most cases, the targets of attacks are the servers of an organization, which means that they should be safeguarded by security measures. In addition, the constant process of creating backup copies must be imperative; this will help bring the company’s IT infrastructure back to operational mode quickly and with minimal financial loss.
In February 2017, we published research on fileless attacks against enterprise networks. We described the data collected during incident response in several financial institutions around the world, exploring how attackers moved through enterprise networks leaving no traces on the hard drives. The goal of these attackers was money, and the best way to cash out and leave no record of transactions is through the remote administration of ATMs. This second paper is about the methods and techniques that were used by the attackers in the second stage of their attacks against financial organizations – basically enabling remote administration of ATMs.
In June 2016, Kaspersky Lab received a report from a Russian bank that had been the victim of a targeted attack. During the heist, the criminals were able to gain control of the ATMs and upload malware to them. After cashing out, the malware was removed. The bank’s forensics specialists were unable to recover the malicious executables because of the fragmentation of a hard drive after the attack, but they were able to restore the malware’s logs and some file names.
The bank’s forensic team were able, after careful forensic analysis of the ATM’s hard drive, to recover the following files containing logs:
In addition, they were able to find the names of two deleted executables. Unfortunately, they were not able to recover any of the contents:
Within the log files, the following pieces of plain text were found:
[Date – Time]
[%d %m %Y – %H : %M : %S] > Entering process dispense.
[%d %m %Y – %H : %M : %S] > Items from parameters converted successfully. 4 40
[%d %m %Y – %H : %M : %S] > Unlocking dispenser, result is 0
[%d %m %Y – %H : %M : %S] > Catch some money, bitch! 4000000
[%d %m %Y – %H : %M : %S] > Dispense success, code is 0
As mentioned in the previous paper, based on the information from the log file we created a YARA rule to find a sample, in this case: MD5 cef6c2aa78ff69d894903e41a3308452. And we’ve found one. This sample was uploaded twice (from Kazakhstan and Russia) as “tv.dll”.
The malware, which we have dubbed ATMitch, is fairly straightforward. Once remotely installed and executed via Remote Desktop Connection (RDP) access to the ATM from within the bank, the malware looks for the “command.txt” file that should be located in the same directory as the malware and created by the attacker. If found, the malware reads the one character content from the file and executes the respective command:
- ‘O’ – Open dispenser
- ‘D’ – Dispense
- ‘I’ – Init XFS
- ‘U’ – Unlock XFS
- ‘S’ – Setup
- ‘E’ – Exit
- ‘G’ – Get Dispenser id
- ‘L’ – Set Dispenser id
- ‘C’ – Cancel
After execution, ATMitch writes the results of this command to the log file and removes “command.txt” from the ATM’s hard drive.
The sample “tv.dll” successfully retrieved in this case does not try to conceal itself within the system.
The malware’s command parser
The malware uses the standard XFS library to control the ATM. It should be noted that it works on every ATM that supports the XFS library (which is the vast majority).
Unfortunately, we were unable to retrieve the executables (!A.exe and IJ.exe, located in C:\ATM) from the ATM; only the file names were found as artefacts during the forensic analysis. We assume that these are the installer and uninstaller of the malware. It should also be noted that “tv.dll” contained one Russian-language resource.
Kaspersky Lab continues to monitor and track these kinds of threats and reiterates the need for whitelisting in ATMs as well as the use of anti-APT solutions in banking networks.
In February 2017 an article in the Polish media broke the silence on a long-running story about attacks on banks, allegedly related to the notoriously known Lazarus Group. While the original article didn’t mention Lazarus Group it was quickly picked up by security researchers. Today we’d like to share some of our findings, and add something new to what’s currently common knowledge about Lazarus Group activities, and their connection to the much talked about February 2016 incident, when an unknown attacker attempted to steal up to $851M USD from Bangladesh Central Bank.
Since the Bangladesh incident there have been just a few articles explaining the connection between Lazarus Group and the Bangladesh bank heist. One such publication was made available by BAE systems in May 2016, however it only included analysis of the wiper code. This was followed by another blogpost by Anomali Labs, confirming the same wiping code similarity. This similarity was found to be satisfying to many readers, however at Kaspersky Lab, we were looking for a stronger connection.
Other claims that Lazarus was the group behind attacks on the Polish financial sector, came from Symantec in 2017, which noticed string reuse in malware at one of their Polish customers. Symantec also confirmed seeing the Lazarus wiper tool in Poland at one of their customers. However, from this it’s only clear that Lazarus might have attacked Polish banks.
While all these facts are fascinating, the connection between Lazarus attacks on banks, and their role in attacks on banks’ systems, was still loose. The only case where specific malware targeting the bank’s infrastructure used to connect to SWIFT messaging server was discovered, is the Bangladesh Central Bank case. However, while almost everybody in the security industry has heard about the attack, few technical details have been revealed to the public based on the investigation that took place on site at the attacked company. Considering that the afterhack publications by the media mentioned that the investigation stumbled upon three different attackers, it was not obvious whether Lazarus was the one responsible for the fraudulent SWIFT transactions, or if Lazarus had in fact developed its own malware to attack banks’ systems.
We would like to add some strong facts that link some attacks on banks to Lazarus, and share some of our own findings as well as shed some light on the recent TTPs used by the attacker, including some yet unpublished details from the attack in Europe in 2017.
This is the first time we announce some Lazarus Group operations that have thus far gone unreported to the public. We have had the privilege of investigating these attacks and helping with incident response at a number of financial institutions in South East Asia and Europe. With cooperation and support from our research partners, we have managed to address many important questions about the mystery of Lazarus attacks, such as their infiltration method, their relation to attacks on SWIFT software and, most importantly, shed some light on attribution.
Lazarus attacks are not a local problem and clearly the group’s operations span across the whole world. We have seen the detection of their infiltration tools in multiple countries in the past year. Lazarus was previously known to conduct cyberespionage and cybersabotage activities, such as attacks on Sony Pictures Entertainment with volumes of internal data leaked, and many system harddrives in the company wiped. Their interest in financial gain is relatively new, considering the age of the group, and it seems that they have a different set of people working on the problems of invisible money theft or the generation of illegal profit. We believe that Lazarus Group is very large and works mainly on infiltration and espionage operations, while a substantially smaller units within the group, which we have dubbed Bluenoroff, is responsible for financial profit.
The watering hole attack on Polish banks was very well covered by media, however not everyone knows that it was one of many. Lazarus managed to inject malicious code in many other locations. We believe they started this watering hole campaign at the end of 2016 after their other operation was interrupted in South East Asia. Lazarus/Bluenoroff regrouped and rushed into new countries, selecting mostly poorer and less developed locations, hitting smaller banks because they are, apparently, easy prey.
To date, we’ve seen Bluenoroff attack four main types of targets:
- Financial institutions
- Companies involved in the development of financial trade software
- Crypto-currency businesses
Here is the full list of countries where we have seen Bluenoroff watering hole attacks:
- Russian Federation
Of course, not all attacks were as successful as the Polish attack case, mainly because in Poland they managed to compromise a government website. This website was frequently accessed by many financial institutions making it a very powerful attack vector. Nevertheless, this wave of attacks resulted in multiple infections across the world, adding new hits to the map we’ve been building.
One of the most interesting discoveries about Lazarus/Bluenoroff came from one of our research partners who completed a forensic analysis of a C2 server in Europe used by the group. Based on the forensic analysis report, the attacker connected to the server via Terminal Services and manually installed an Apache Tomcat server using a local browser, configured it with Java Server Pages and uploaded the JSP script for C2. Once the server was ready, the attacker started testing it. First with a browser, then by running test instances of their backdoor. The operator used multiple IPs: from France to Korea, connecting via proxies and VPN servers. However, one short connection was made from a very unusual IP range, which originates in North Korea.
In addition, the operator installed an off-the-shelf cryptocurrency mining software that should generate Monero cryptocoins. The software so intensely consumed system resources that the system became unresponsive and froze. This could be the reason why it was not properly cleaned, and the server logs were preserved.
This is the first time we have seen a direct link between Bluenoroff and North Korea. Their activity spans from backdoors to watering hole attacks, and attacks on SWIFT servers in banks of South East Asia and Bangladesh Central Bank. Now, is it North Korea behind all the Bluenoroff attacks after all? As researchers, we prefer to provide facts rather than speculations. Still, seeing IP in the C2 log, does make North Korea a key part of the Lazarus Bluenoroff equation.Conclusions
Lazarus is not just another APT actor. The scale of the Lazarus operations is shocking. It has been on a spike since 2011 and activities didn’t disappear after Novetta published the results of its Operation Blockbuster research, in which we also participated. All those hundreds of samples that were collected give the impression that Lazarus is operating a factory of malware, which produces new samples via multiple independent conveyors.
We have seen them using various code obfuscation techniques, rewriting their own algorithms, applying commercial software protectors, and using their own and underground packers. Lazarus knows the value of quality code, which is why we normally see rudimentary backdoors being pushed during the first stage of infection. Burning those doesn’t impact the group too much. However, if the first stage backdoor reports an interesting infection they start deploying more advanced code, carefully protecting it from accidental detection on disk. The code is wrapped into a DLL loader or stored in an encrypted container, or maybe hidden in a binary encrypted registry value. It usually comes with an installer that only attackers can use, because they password protect it. It guarantees that automated systems – be it a public sandbox or a researcher’s environment – will never see the real payload.
Most of the tools are designed to be disposable material that will be replaced with a new generation as soon as they are burnt. And then there will be newer, and newer, and newer versions. Lazarus avoids reusing the same tools, same code, and the same algorithms. “Keep morphing!” seems to be their internal motto. Those rare cases when they are caught with same tools are operational mistakes, because the group seems to be so large that one part doesn’t always know what the other is doing.
This level of sophistication is something that is not generally found in the cybercriminal world. It’s something that requires strict organisation and control at all stages of operation. That’s why we think that Lazarus is not just another APT actor.
Of course such processes require a lot of money to keep running, which is why the appearance of the Bluenoroff subgroup within Lazarus was logical.
Bluenoroff, being a subgroup of Lazarus, is focusing on financial attacks only. This subgroup has reverse engineering skills because they spend time tearing apart legitimate software, and implementing patches for SWIFT Alliance software, in attempts to find ways to steal big money. Their malware is different and they aren’t exactly soldiers that hit and run. Instead, they prefer to make an execution trace to reconstruct and quickly debug the problem. They are field engineers that come when the ground is already cleared after conquering new lands.
One of Bluenoroff’s favorite strategies is to silently integrate into running processes without breaking them. From the code we’ve seen, it looks as if they are not exactly looking for a hit and run solution when it comes to money theft. Their solutions are aimed at invisible theft without leaving a trace. Of course, attempts to move around millions of USD can hardly remain unnoticed, but we believe that their malware might be secretly deployed now in many other places and it isn’t triggering any serious alarms because it’s much more quiet.
We would like to note, that in all of the observed attacks against banks that we have analyzed, SWIFT software solutions running on banks’ servers haven’t demonstrated or exposed any specific vulnerability. The attacks were focused on banking infrastructure and staff, exploiting vulnerabilities in commonly used software or websites, bruteforcing passwords, using keyloggers and elevating privileges. However, the way banks use servers with SWIFT software installed requires personnel responsible for the administration and operation. Sooner or later, the attackers find these personnel, gain the necessary privileges, and access the server connected to the SWIFT messaging platform. With administrative access to the platform they can manipulate software running on the system as they wish. There is not much that can stop them, because from a technical perspective, their activities may not differ from what an authorized and qualified engineer would do: starting and stopping services, patching software, modifying the database. Therefore, in all the breaches we have analyzed, SWIFT, as an organization has not been at direct fault. More than that, we have witnessed SWIFT trying to protect its customers by implementing the detection of database and software integrity issues. We believe that this is a step in the right direction and these activities should be extended with full support. Complicating the patches of integrity checks further may create a serious threat to the success of future operations run by Lazarus/Bluenoroff against banks worldwide.
To date, the Lazarus/Bluenoroff group has been one of the most successful in launching large scale operations against the financial industry. We believe that they will remain one of the biggest threats to the banking sector, finance and trading companies, as well as casinos for the next few years. We would like to note that none of the financial institutions we helped with incident response and investigation reported any financial loss.
As usual, defense against attacks such as those from Lazarus/Bluenoroff should include a multi-layered approach. Kaspersky products include special mitigation strategies against this group, as well as the many other APT groups we track. If you are interested in reading more about effective mitigation strategies in general, we recommend the following articles:
We will continue tracking the Lazarus/Bluenoroff actor and share new findings with our intel report subscribers, as well as with the general public. If you would like to be the first to hear our news, we suggest you subscribe to our intel reports.
For more information, contact: email@example.com.
Back to the Future – SAS 2016
As Thomas Rid left the SAS 2016 stage, he left us with a claim that turned the heads of the elite researchers who filled the detective-themed Tenerife conference hall. His investigation had turned up multiple sources involved in the original investigation into the historic Moonlight Maze cyberespionage campaign who claimed that the threat actor had evolved into the modern day Turla. What would this all mean?The Titans of Old
Moonlight Maze is the stuff of cyberespionage legend. In 1996, in the infancy of the Internet, someone was rummaging through military, research, and university networks primarily in the United States, stealing sensitive information on a massive scale. Victims included the Pentagon, NASA, and the Department of Energy, to name a very limited few. The scale of the theft was literally monumental, as investigators claimed that a printout of the stolen materials would stand three times taller than the Washington Monument.
To say that this historic threat actor is directly related to the modern day Turla would elevate an already formidable modern day attacker to another league altogether. Turla is a prolific Russian-speaking group known for its covert exfiltration tactics such as the use of hijacked satellite connections, waterholing of government websites, covert channel backdoors, rootkits, and deception tactics. Its presumed origins track back to the famous Agent.BTZ, a campaign to spread through military networks through the use of USB keys that took formidable cooperation to purge (in the form of an interagency operation codenamed Buckshot Yankee in 2008). Though mitigating the threat got the most attention at the time, further research down the line saw this toolkit connecting directly to the modern Turla.
Further confirmation came through our own Kurt Baumgartner’s research for Virus Bulletin 2014 when he discovered Agent.BTZ samples that contacted a hijacked satellite IP jumping point, the same that was used by Turla later on. This advanced exfiltration technique is classic Turla and cemented the belief that the Agent.BTZ actor and Turla were one and the same. This would place Turla back as early as 2006-2007. But that’s still a decade ahead of the Moonlight Maze attack.
By 2016 the Internet was over-crowded with well-resourced cyberespionage crews. But twenty years ago there were few players in this game. Few paid attention to cyberespionage. In retrospect, we know that the Equation Group was probably active at this time. A command-and-control registration places Equation in the mid-1990s. That makes Equation the longest running cyberespionage group/toolkit in history. To then claim that Turla, in one form or another, was active for nearly as long, places them in a greater league than their pre-historic counterpart in pioneering state-sponsored cyberespionage.A Working Hypothesis
By the time of the SAS 2016 presentation, we had already discussed at length how one might go about proving this link. The revelation that the Moonlight Maze attacks were dependent on a Solaris/*NIX toolkit and not a Windows one as is the case with most of Turla, actually revived our hopes. We would not have to look for older Windows samples where so far there were none, but could instead focus on another discovery. In 2014, Kaspersky announced the discovery of Penquin Turla, a Linux backdoor leveraged by Turla in specific attacks. We turned our attention once again to the rare Penquin samples and noticed something interesting: the code was compiled for the Linux Kernel versions 2.2.0 and 2.2.5, released in 1999. Moreover, the statically linked binaries libpcap and OpenSSL corresponded to versions released in the early 2000s. Finally, despite the original assessment incorrectly surmising that Penquin Turla was based on cd00r (an open-source backdoor by fx), it was actually based on LOKI2, another open-source backdoor for covert exfiltration written by Alhambra and daemon9 and released in Phrack in the late 1990s. This all added up to an extremely unusual set of circumstances for malware that was leveraged in attacks in from 2011-2016, with the latest Penquin Sample discovered just a month ago being submitted from a system in Germany.
Kurt Baumgartner’s prescient observation upon the discovery of the first Penquin Turla samples
Our working hypothesis became this: “The Turla developers decided to dust down old code and recompile it for current Windows victims in the hope of getting a stealthier beachhead on systems that are less likely to be monitored.” Were that to be the case, Penquin Turla could be the modern link that tied Turla to Moonlight Maze. But in order to prove our hypothesis and this historic evolution, we’d need a glimpse at the original artefacts, something we had no access to.The Cupboard Samples
Our last hope was that someone somewhere had kept a set of backups collecting dust in a cupboard that they might be willing to share. Thomas took to the road to follow up his sources and eventually stumbled upon something remarkable. The Moonlight Maze operators were early adopters of a certain degree of operational security, using a series of hacked servers as relays to mask their original location. During the later stages of their campaign, they hacked a Solaris box in the U.K. to use as a relay. Unbeknown to them, the system administrator—in cooperation with the Metropolitan Police in London and the FBI—turned the server against the malicious operators. The machine known as ‘HRTest’ would proceed to log everything the attackers did keystroke-by-keystroke and save each and every binary and archive that transited through it. This was a huge win for the original investigators and provided something close to a six-month window of visibility before the attackers ditched this relay site (curiously, as a result of the campaign’s first publicity in early March 1999). Finding these samples was hard and fortuitous—due to a redaction error in an FBI FOIA release, we were able to ultimately track down David Hedges after about a year of sleuthing. “I hear you’re looking for HRTest,” David said when he finally called Thomas for the first time. Then, the now-retired administrator kicked a machine under his desk, chuckling as he said “well it’s sitting right here, and it’s still working.”
Thomas Rid, David Hedges, Daniel Moore, and Juan Andres Guerrero-Saade at King’s College LondonPaydirt but not the Motherlode
What we had in our hands allowed us to recreate a portion of the constellation of attacks that constitutes Moonlight Maze. The samples and logs became our obsession for months. While Juan Andres and Costin at GReAT reversed the binaries (most compiled in SPARC for Solaris and MIPS for IRIX, ancient assembly languages), Daniel Moore went so far as to create an entire UI to parse and load the logs onto, so as to be able to visualize the extent of the networks and nodes under attack. We set out to profile our attackers and understand their methods. Among these, some salient features emerged:
Moore’s Rapyd Graph Data Analyzer tracking the victims of Moonlight Maze linked to HRTest
- The attackers were prolific Unix users. They used their skills to script their attack phases, which allowed a sort of old school automation. Rather than have the malware communicate to command-and-control servers and carry out functions and exfiltration of their own accord, the attackers would manually log in to victim nodes and leverage scripts and tasking files (usually located in the /var/tmp/ directory) to instruct all of these nodes on what they should do, what information to collect, and finally on where to send it. This allowed them to orchestrate large swaths of infected machines despite being an ‘operator-at-keyboard’ style of attack.
- The operators were learning as they went. Our analysis of the binaries shows a trial and error approach to malware development. Many binaries were simply open-source exploits leveraged as needed. Others were open-source backdoors and sniffers. However, despite not having exact compilation timestamps (as would happen in Windows executables), it’s possible to trace a binary evolution of sorts. The devs would test out new capabilities, then recompile binaries to fix issues and expand functionality as needed. This allowed us to graph a sort of binary tree of development to see how the attacks functionalities developed throughout this campaign.
- Despite their early interest in OpSec, and use of tools specifically designed for this effect, the operators made a huge mistake. It was their standard behavior to use infected machines to look for further victims on the same network or to relay onto other networks altogether. In more than a dozen cases, the attackers had infected a machine with a sniffer that collected any activity on the victim machine and then proceeded to use these machines to connect to other victims. That meant that the attackers actually created near complete logs of everything they themselves did on these systems—and once they did their routine exfiltration, those self-logs were saved on the HRTest node for posterity. The attackers created their own digital footprint for perpetuity.
A complete analysis of the attack artefacts is provided in the whitepaper, for those interested in a look under the hood of a portion of the Moonlight Maze attacks. For those who would like to jump straight to the conclusion: our parallel investigation into the connection between Moonlight Maze and Turla yielded a more nuanced answer predicated upon the limitations in our visibility.
An objective view of the investigation would have to admit that a conclusion is simply premature. The unprecedented public visibility into the Moonlight Maze attack provided by David Hedges is fascinating, but far from complete. It spans a window between 1998-1999 as well as samples apparently compiled as far back as late 1996. On the other hand, the Penquin Turla codebase appears to have been primarily developed from 1999-2004 before being leveraged in more modern attacks. What we are left with is a circumstantial argument that takes into account the binary evolution witnessed from 1998-1999 as well as the functionality and tools leveraged at that time, both of which point us to a development trend that could lead directly to what is now known as Penquin Turla. This includes the use of tasking files, LOKI2 for covert channel communications, and promiscuous sniffers – all of which made it into the modern Penquin Turla variants.
The next step in our ongoing parallel investigation would have to focus on a little known operation codenamed ‘Storm Cloud’. This codename represents the evolved toolkit leveraged by the same Moonlight Maze operators once the initial intrusions became public in 1999. In 2003, the story of Storm Cloud leaked with little fanfare, but a few prescient details led us to believe a more definitive answer may be found in this intrusion set:
Storm Cloud reference in a 2003 Wall Street Journal Article mentions further use of LOKI2
Just as the SAS 2016 talk enabled us to find David and his time capsule of Moonlight Maze artefacts, we hope this glimpse into our ongoing research will bring another dedicated sysadmin out of the woodwork who may still have access to Storm Cloud artefacts, allowing us to settle this question once and for all. Beyond the historical value of this understanding, it would afford greater perspective into a tool being leveraged in cyberespionage attacks to this day.
The epic Moonlight Maze hunt continues…
If you have information or artefacts you’d like to share with the researchers, please contact penquin[at]kaspersky.com
As numerous studies have shown, smart houses, smart cars, and smart cities are undeniably beneficial to people in everyday life, but quite often can become a threat to their safety. It is not only a matter of personal data leakage. Just imagine that, for example, a smart refrigerator, affected by a third party at one point or another, would begin identifying expired products as fresh. There is yet another more dismal scenario: the system of a smart car turns the vehicle to the right at high speed, catching the driver unaware…
However, both existing and predictable threats that emerge from home IoT devices are only part of the problem related to the infrastructure around us becoming “smarter”. A technological boom in medicine both encouraged medical institutions to use exclusively information systems in processing data and led to the emergence of new types of technological equipment and personal devices that can be used to interact with traditional systems and networks. This means that the threats that are relevant for them can also be relevant for medical systems.Entry Points for Accessing Valuable Data
For the medical industry, the main attack vector is related to personal data and information on the health condition of patients. The first step in evaluating the security level for data is identifying entry points within the infrastructure of medical institutions where healthcare data can be collected, stored, and/or taken advantage of by an evildoer.
Possible entry points can be classified as follows:
- information systems on the computer network of a medical institution (servers, workstations, admin panels for medical equipment, etc.) that access the Internet;
- medical equipment that is connected to an enterprise network;
- medical equipment that is not a network node but connects to a workstation (for example, via USB);
- portable devices of patients (advanced fitness trackers, pacemakers and cardiac monitors, insulin pumps, etc.) and mobile devices that can track health indicators (mobile smartphones and smart watches);
- other wireless information systems (Wi-Fi, Bluetooth, or RF), which can be mobile ECG devices, pulse oximeters, event monitors for tracking the medical condition of high-risk patients, and so on.
For the last three classes mentioned above, a detailed first-hand analysis of specific models related to these classes is required. It is for exactly this reason that those devices deserve an article of their own. For now, we will focus on devices and their components that do not require physical access and are frequently accessible from the Internet.Portable Devices May Port Medical Histories
We’ve already written the following about the security of portable devices in March of 2015: “Just imagine, if a fitness tracker with a heart-rate monitor is hacked, then any shop owner will be able to track the heart rate of buyers as they look at discounts in the shop. The influence of advertisements on people can be learned in the same manner. Moreover, a hacked fitness tracker with a heart-rate monitor can be used as a lie detector.”
Owing to the increasing accuracy of sensors, gadgets that collect data on the health condition of their owners can potentially be used in serious ambulatory care to assess a patient’s health. However, the level of security for these gadgets has not been developing as fast as their capabilities.
Tracking vital signs with the help of mobile devices may become an integral part of ambulatory care in the nearest future
Information that is collected by tracking vital signs can be used by both the owner of the device and the vendor of the infrastructure that the tracking app operates on. For users, the heart-rate parameter can signify that a certain activity should be decreased, specific medicines should be taken, etc., while vendors can send collected data to medical companies that can use it to assess the overall health of the client.
Thus, the main advantage of data collected by a gadget is not the depth of its analysis (any medical examination will yield more accurate results than readings from a fitness tracker) but the ability to evaluate changes in a patient’s health condition dynamically. Scenarios for using the information are limited by the imagination and enterprise of the owner, as well as by laws related to personal data.
If we look at the same piece of information from the perspective of a cybercriminal, then an owner of such a device will have not the most favorable outlook – analysis of certain parameters (for example, heart rate, sleep quality, or average ADL score) allows a criminal to gain an overview of a victim’s health. Any additional information may be provided by a gadget that is connected to the mobile device and is capable, for instance, of measuring the blood pressure or blood sugar levels of its user. After making conclusions about the ailments of a victim, an evildoer can provoke their aggravation.
Attacks to obtain health data can be divided into three basic types: those that violate data privacy, those that compromise data integrity, and those that attack data availability. Main vectors can be defined for each of those.
Types of attack that violate the privacy of medical data:
- man-in-the-middle attacks on a sensor channel between the sensor and the service that stores the sensor’s data;
- unauthorized access to local and remote data storage.
Types of attacks on data integrity:
- unauthorized access to data storage with possible data substitution;
- man-in-the-middle spoofing attacks on channels in order to substitute transmitted data;
- modification (substitution) of data (spoofing attacks) and their transmission to consumers (as a service that stores data or an app).
Attacks on availability:
- ransomware attacks (encryption/deletion of user data).
Entry points for malicious code that commits theft or substitutes data on a mobile device depend on a specific combination of device and software.Online Medical Data
Yet, I would like to review another entry point in detail – information systems on a medical institution’s network that are accessible from the Internet.
Medical institutions utilize automated healthcare data storage solutions, which store miscellaneous information about patients (diagnosis results, information about prescribed drugs, medical histories, etc.). The infrastructure of such a system may include various hardware and software components, which can be merged into data storage networks and can be accessible from the Internet in one form or another.
Regarding solutions for storage of healthcare data, several software packages, which can be exploited as entry points into medical infrastructure, can be given as examples.
- Hospital information systems (HISs) are software packages that control medical information coming from various sources, including the systems mentioned below.
- Electronic Health Records (EHR) systems are dedicated software that enable storage of structured patient data and documentation of patient medical history.
- Network-attached storage (NAS) refers to dedicated network storage devices, which can be both specialized devices for storing healthcare data or enterprise devices employed in the medical-institution
- DICOM-complaint (Digital Imaging and Communications in Medicine) devices and PACS (picture archiving and communication system) servers are medical information systems based on the DICOM standard and include the following components:
- a DICOM client, which is a medical device that is capable of transmitting data to a DICOM server;
- a DICOM server, which is a hardware and software package that provides for the receipt and storage of data from clients (in particular, these devices can be PACS servers);
- a DICOM diagnostic workstation and DICOM printers, both of which are hardware and software packages that are responsible for processing, visualizing, and printing medical images.
A key feature of the above-mentioned systems is a web interface (a web app) that is used to control them over the Internet. A web interface may have vulnerabilities that can be exploited by an evildoer, who can gain access to valuable information and processes. It is worth reviewing these systems in detail and verifying whether they are accessible from the Internet, i.e. if they are a potential entry point for evildoers.Electronic Health Records (EHR)
In order to evaluate the number of apps that are available from the outside (from the Internet) and can work with EHR, a list of software employed in these tasks should be created and then a dork list should be organized. Dorks are special search-engine queries that are aimed at finding web components of required software among all of the resources indexed by a search engine.
Here is an example of a dork query that uses Google to search for the login form of EHR software components:
intitle:”<vendor_name> Login” & inurl:<vendor name>
The example of a discovered web component (a login form) of software that is intended to work with EHR
It should be noted that some of the resources found in the search results turned out to be traps for evildoers (honeypots). This fact alone indicates that analysts are seeking to track threats related to medical infrastructure. To check if an identified resource is a honeypot, an IP address should be submitted to a special service, HoneyScore, which, by scanning a number of the resource’s attributes (for example, the hosting provider), reaches a verdict on whether or not the resource is a honeypot. Nevertheless, a significant part of the discovered resources is represented by actual systems.
126 discovered resources that meet the search criteria
Each of the discovered web resources is a potential entry point that can be exploited by an evildoer to access the infrastructure. For example, many discovered systems lack protection against an exhaustive password search, which means that a criminal can use brute-force attacks. Then, by using a hacked account, the evildoer can gain privileged access to the system through the interface or find or exploit online vulnerabilities in order to access the system in the future.
An example of a discovered web interface for logging into an EHR systemHospital Information Systems (HISs)
A “hospital information system” is quite a vast notion that includes a set of methods and technologies for processing medical information. In our case, we are interested only in the HIS components that have a web interface for controlling and visualizing medical information.
Let’s consider the software of OpenEMR as an example. This software is used in medical institutions as a medical-data management solution, and it is certified by the Office of the National Coordinator for Health Information Technology (ONC). Some of its components are written in the PHP programming language, which means that a potential entry point for an evildoer can be a web server that maintains these OpenEMR components.
The next Google dork query returned 106 search results that meet the following criterion:
inurl:”/interface/login/login_frame.php” intitle:”Login” intext:”Username:”
After a quick analysis of the search results, it became obvious that components of the majority of the discovered OpenEMR systems have vulnerabilities, including some critical ones. This means that these vulnerabilities open up the OpenEMR database to being compromised. This comes with the fact that exploits for the discovered vulnerabilities are publicly available.
An example of a vulnerable HIS that was openly exposed
For example, analyzing different software versions revealed that information had been published on the vulnerabilities for the vast majority of software installed on the hosts.OpenEMR version Number of hosts (%) Availability of public exploits 4.2.0 31,4 Yes 4.1.2 14,3 Yes 4.1.0 11,4 Yes 4.2.1 5,7 No 4.0.0 5,7 Yes 4.1.1 2,8 Yes 4.3.1-dev 2,8 No 2.8.3 2,8 Yes 3.2.0 2,8 Yes Proprietary (modified) version 8,5 – Unknown version 11,4 – Network Attached Storage (NAS)
There are at least two types of NAS servers that have been used by medical institutions: dedicated “medical” NAS servers and common ones. While the former have strict security requirements for the data stored on them (for example, compliance with the Health Insurance Portability and Accountability Act), the security of the latter rests on the conscience of their developers and the medical institutions that use this type of NAS in their infrastructure. As a result, non-medical NAS may be left working without any updates for years and thus gather a great number of known vulnerabilities.
A list of dorks should be created to select NAS devices located in medical institutions out of all of the other devices indexed by search engines.
The next query is for the Censys search engine, which specializes in indexing devices with IP addresses and finds all of the devices (workstations, servers, routers, NAS servers, etc.) that belong to companies whose names contain words that directly or indirectly define these companies as medical institutions (“healthcare”, “clinic”, “hospital”, and “medical”):
autonomous_system.organization: (hospital or clinic or medical or healthcare)
The Censys search engine found approximately 21,278 hosts that are related to medical institutions
The Censys report, which is shown below, lists the top 10 countries where these hosts are located.Country Hosts United States 18 926 Canada 1113 Iran 441 Saudi Arabia 379 Republic of Korea 135 Australia 81 Thailand 33 United Kingdom 32 Puerto Rico 28 Vietnam 27
Afterward, only those hosts that are FTP servers can be taken out from the search results that contain the hosts. In order to do this, the query in the search engine should be more specific and, for example, only the hosts that contain an open FTP port and whose banners contain the “FTP” line should be searched for (this is the information that a server sends to a client during attempts to connect to its port):
(tags: ftp) and autonomous_system.organization: (health or clinic or medical or healthcare)
The search results displayed 1,094 hosts with operational FTP servers, which presumably belong to medical institutions.
Additionally, a list of vendor-specific NAS devices can be obtained from the narrowed-down search results. For this, the typical characteristics of a device must be known. These may be included in responses from services that are active on the device (for example, an FTP-server response to a connection attempt may contain the name of the device and its firmware version). The next query allows for selection of only those hosts that contain the “NAS” line in their banner (generally, several QNAP Systems models have this property) from all found hosts:
(metadata.description: nas) and autonomous_system.organization: (health or clinic or medical or healthcare)
The discovered QNAP Systems NAS servers that belong to medical organizations
A ProFTPd web-server release that has vulnerabilities was installed on each of the found NAS. For this release, there is also publicly available and easily accessible information about its exploits.
The most common type of devices that utilize the DICOM format are PACS servers that print patient images that have been received from other DICOM devices.
It is possible to enter the following primitive query in the Shodan search engine to start searching for DICOM devices:
Accordingly, the search results will display hosts (mostly workstations and servers) that are used in medical institutions for storing and processing patient DICOM images.
The list of hosts that are used to process/store DICOM images
Also, it might be worth searching for diagnostic DICOM workstations, which are dedicated PACS systems used for processing, diagnosing, and visualizing data. As an example, the following query for the Censys search engine can be used:
pacs and autonomous_system.organization: (hospital or clinic or medical or healthcare)
Analysis of the search results may reveal dedicated software for a diagnostic workstation.
The login forms of diagnostic workstations used for visualization of patient data
Aside from that, there are also admin panels used to access DICOM servers in the search results.
A login form for accessing a DICOM serverNon-medical Systems with “Pathologies”
The systems described above handle valuable medical data. Therefore, security requirements for those systems must be high. However, let’s not forget that besides potential entry points, there are dozens of other points an evildoer can use that are not directly related to medical systems but are located in the infrastructure along with valuable data.
Here are several examples of non-medical systems that can be used as a potential entry point into a computer network with the goal of subsequently moving on to resources where medical information is stored:
- any servers (web servers, FTP servers, e-mail servers, etc.) that are connected to the network of an institution and are accessible from the Internet;
- a medical institution’s public Wi-Fi hotspots;
- office printers;
- video surveillance systems;
- SCADA controllers;
- automated systems for controlling mechanical and electrical components of a building (building management systems, BMS).
Each of the mentioned systems may have a vulnerability that can be taken advantage of by an evildoer in order to gain access to medical infrastructure.
For example, the popularity of the Heartbleed vulnerability can be evaluated. This requires entering the following query into the Censys search engine:
autonomous_system.organization: (hospital or clinic or medical or healthcare) and 443.https.heartbleed.heartbleed_vulnerable: 1
The search engine showed 66 hosts that met the criteria and were potentially vulnerable to Heartbleed. Additionally, this was after the existence of the vulnerability, and its dangers had been given wide coverage by the mass media. Generally speaking, when referring to Heartbleed, it should be noted that the problem is global in nature. According to a report by the founder of Shodan, approximately 200,000 websites still remain vulnerable.Stay Healthy
In order keep evildoers from stealing medical data from institutions, we, along with taking essential security measures typical for enterprise infrastructure, recommend doing the following:
- exclude from external access all of the information systems that process medical data or any other patient-related data;
- all of the medical equipment that connects to a workstation (or is a network node) should be isolated in a dedicated segment, while the operational parameters of the equipment can be modified by using the workstation (or remotely);
- any online information systems should be isolated in a “demilitarized” zone or completely excluded from an enterprise network;
- continuously monitor medical-system software for updates and update software regularly;
- change default passwords that are set up for the login forms of medical systems and delete unwanted accounts from the database (for example, test accounts);
- create strong passwords for all accounts.
The Kaspersky Lab Industrial Control Systems Cyber Emergency Response Team (Kaspersky Lab ICS CERT) is starting a series of regular publications about our research devoted to the threat landscape for industrial organizations.
All statistical data used in the report was obtained using Kaspersky Security Network (KSN), a distributed antivirus network. Data was received from those KSN users who consented to have their data collected anonymously.
The research carried out in the second half of 2016 by Kaspersky Lab ICS CERT experts clearly demonstrates a number of trends in the evolution of industrial enterprise security.
On average, in the second half of 2016 Kaspersky Lab products across the globe blocked attempted attacks on 39.2% of protected computers that Kaspersky Lab ICS CERT classifies as being part of industrial enterprise technology infrastructure.
This group includes computers that run Windows and perform one or more of the following functions:
- Supervisory Control and Data Acquisition (SCADA) servers,
- Data storage servers (Historian),
- Data gateways (OPC),
- Stationary engineer and operator workstations,
- Mobile engineer and operator workstations,
- Human Machine Interface (HMI).
The group also includes computers of external 3-d party contractors, SCADA vendors and system integrators as well as internal SCADA administrators.
Every month, an average of one industrial computer in five (20.1%) is attacked by malware. We have seen stable growth in the percentage of industrial computers attacked since the beginning of our observations, highlighting the importance of cybersecurity issues.
Percentage of industrial computers attacked by month (second half of 2016)
- Isolation of industrial networks can no longer be considered an effective protective measure. The proportion of malware infection attempts involving portable media, infection of backup copies, use of sophisticated schemes for transferring data from isolated networks in complex attacks – all of this demonstrates that risks cannot be avoided by simply disconnecting a system from the Internet.
Sources of threats blocked on industrial computers (second half of 2016)
- Remarkably, there is very little difference between the rankings of malware detected on industrial computers and those of malware detected on corporate computers. We believe that this demonstrates the absence of significant differences between computers on corporate networks and those on industrial networks in terms of the risk of chance infections. However, it is obvious that even a chance infection on an industrial network can lead to dangerous consequences.
According to our data, targeted attacks on companies in different industrial sectors are increasingly common. These are organized attacks that can target one enterprise, several enterprises, companies in one industrial sector or a broad range of industrial enterprises.
The Kaspersky Lab ICS CERT detected a series of phishing attacks which began no later than June 2016 and which are still active. The attacks target primarily industrial companies – metallurgical, electric power, construction, engineering and others. We estimate the number of companies attacked at over 500 in more than 50 countries around the world.
None of the malicious programs used in the attack – trojan spies and backdoors from different families, such as ZeuS, Pony/FareIT, Luminosity RAT, NetWire RAT, HawkEye, and ISR Stealer – are unique to this malicious campaign. They are all very popular among cybercriminals. However, these programs are packed with unique modifications of VB and MSIL packers that are used only in this attack. Our experience of investigating targeted attacks shows that cyberespionage is often used to prepare subsequent attack stages.
One quarter of all targeted attacks uncovered by Kaspersky Lab in 2016 targeted, among others, different industries – machine building, energy, chemical, transport and others.
In 2016, Kaspersky Lab evaluated the current state of IT security components in the industrial control systems of different vendors. As a result of this research, 75 vulnerabilities were identified in ICS components. 58 of them were marked as maximum critical vulnerabilities (CVSS v3.0 severity score 7.0 or higher).
Distribution of industrial computers attacked by classes of malware used in attacks (second half of 2016)
Distribution of vulnerabilities uncovered by Kaspersky Lab in 2016 according to the ways in which they can be used
Of the 75 vulnerabilities identified by the middle of March 2017 by Kaspersky Lab, industrial software vendors closed 30.
The approach of industrial software vendors to closing vulnerabilities and the situation with fixing known vulnerabilities at enterprises is by no means reassuring. The approach to addressing vulnerabilities as part of the software development cycle has not yet been sufficiently refined: vendors do not prioritize the closing of identified vulnerabilities based on their severity, they prefer to fix vulnerabilities in the next release of their product rather than releasing a fix or patch that is critical from an IT security viewpoint.
Another issue is the installation of updates and security patches at enterprises. Based on our research and ICS IT security audits, we believe that for ICS owners, the process of installing critical updates is either too labor-intensive or not a high-priority task in the system’s overall lifecycle. As a result, at some enterprises critical updates of various industrial system components are not installed for years, making these enterprises vulnerable in the event of cyberattacks.
The industrial network is increasingly similar to the corporate network – both in terms of usage scenarios and in terms of technologies used. New technologies are being used that improve process transparency and efficiency at the enterprise level, as well as providing flexibility and fault tolerance of the functions performed at medium and lower industrial automation levels. The upshot of all this is that the cyber threat landscape for industrial systems is increasingly similar to the threat landscape for corporate networks. Consequently, we can expect not only the emergence of new threats specifically designed for industrial enterprises but also the evolution of existing, traditional IT threats, which involves their adaptation for attacks against industrial enterprises and physical world objects.
The emergence of large-scale malicious campaigns targeting industrial enterprises indicates that black hats see this area as promising. This is a serious challenge for the entire community of industrial automation system developers, owners and operators of such systems, and security vendors. We are still remarkably languid and slow-moving in most cases, which is fraught with dangers under the circumstances.
The full report is available on Kaspersky Lab ICS CERT website.
A distributed denial-of-service (DDoS) attack is one of the most popular tools in the cybercriminal arsenal. The motives behind such attacks can vary – from cyber-hooliganism to extortion. There have been cases where criminal groups have threatened their victims with a DDoS attack unless the latter paid 5 bitcoins (more than $5,000). Often, a DDoS attack is used to distract IT staff while another cybercrime such as data theft or malware injection is carried out.
Almost anyone can fall victim to a DDoS attack. They are relatively cheap and easy to organize, and can be highly effective if reliable protection is not in place. Based on analysis of the data obtained from open sources (for example, offers to organize DDoS attacks on Internet forums or in Tor), we managed to find out the current cost of a DDoS attack on the black market. We also established what exactly the cybercriminals behind DDoS attacks offer their customers.DDoS as a service
Ordering a DDoS attack is usually done using a full-fledged web service, eliminating the need for direct contact between the organizer and the customer. The majority of offers that we came across left links to these resources rather than contact details. Customers can use them to make payments, get reports on work done or utilize additional services. In fact, the functionality of these web services looks similar to that offered by legal services.
Example of a web service for ordering DDoS attacks that looks more like the web page of an IT startup than a cybercriminal operation
These web services are fully functional web applications that allow registered customers to manage their balance and plan their DDoS attack budget. Some developers even offer bonus points for each attack conducted using their service. In other words, cybercriminals have their own loyalty and customer service programs.
DDoS service advertised on a Russian public forum offering attacks from $50 per day
Some of the services we identified contained information on the number of registered users, as well as data on the number of attacks carried out per day. Many of the web services offering DDoS attacks claimed to have tens of thousands of registered accounts. However, these figures may be inflated by the owners of services to make their resources look more popular.
Statistics provided by one service to demonstrate its popularity with DDoS customers (479270 implemented attacks)
Statistics provided by one service to demonstrate the popularity of DDoS attack scenarios
Information about the popularity of a DDoS serviceRates for DDoS
The special features emphasized in the adverts for DDoS services can give a particular service an advantage over its competitors and sway the customer’s choice:
The target and its characteristics. A cybercriminal that agrees to attack a government resource will attract customers who are interested in this particular service. The attacker can ask for more money for this type of service than they would for an attack on an online store. The cost of the service may also depend on the type of anti-DDoS protection the potential victim has: if the target uses traffic filtering systems to protect its resources, the cybercriminals have to come up with ways of bypassing them to ensure an effective attack, and this also means an increase in the price.
Attack sources and their characteristics. This factor can determine the price the attackers ask for conducting their attacks. The cheaper it is for a criminal to maintain a botnet (defined, for example, by the average cost of infecting a device and including it in a botnet), the more likely they are to ask for bargain-basement prices for their services. For example, a botnet of 1000 surveillance cameras may be cheaper in terms of organization than a botnet of 100 servers. This is because cameras and other IoT devices are currently less secure – a fact that is often ignored by their owners.
Attack scenario. Requests for atypical DDoS attacks (for example, the customer may ask the botnet owner to alternate between different methods of DDoS attacks within a short period of time or implement several methods simultaneously) can increase costs.
The average cost of a DDoS attack as a service in a particular country. Competition can cause cybercriminals to raise or lower the cost of their services. They also try to take into consideration the ability of their audience to pay and devise their pricing policy accordingly (for example, a DDoS attack will cost US customers more than a similar offer in Russia).
Along with specific botnet features, the organizers of DDoS services also offer customers a tariff plan in which the buyer pays a per-second rental price for botnet capacity. For example, a DDoS attack of 300 seconds using a botnet with a total bandwidth of 125 Gbps will cost €5, with all other characteristics (power and scenarios) remaining the same for all tariffs.
The price list for one of the biggest services offering DDoS attacks
A DDoS attack lasting 10,800 seconds will cost the client $60, or approximately $20 per hour, and the attack specifications (scenario and computing power used) were not always stated on the customer-facing resource. Apparently, not all cybercriminals consider it appropriate to disclose the inner workings of their botnet (it’s also possible that some owners don’t actually understand the technical characteristics of their botnets). In particular, they don’t disclose the type of bots included in a botnet.
The price includes implementation of the following rather trivial scenarios:
- Multi-vector amplification (several amplification scenarios simultaneously).
The price list for a service that, with just a few clicks, allows clients to order a DDoS attack on an arbitrary resource accompanied with a detailed report
Some services offer a choice of attack scenario, which allows cybercriminals to combine different scenarios and perform attacks tailored to the individual characteristics of the victim. For example, if the victim successfully combats SYN-flood, the attacker can switch the scenario on the control panel and evaluate the victim’s reaction.
Various tariffs of an English-language service that varies its pricing according to the number of seconds a DDoS attack lasts
Among the offers we analyzed there were some in which the attackers stated different prices for their services depending on the type of victim.
Information found on a Russian site dedicated entirely to DDoS services
For example, the cybercriminals ask for $400 per day to attack a site/server that uses anti-DDoS protection, which is four times more expensive than an attack on an unprotected site.
Moreover, not all cybercriminals offering DDoS attacks will agree to attack government resources: such sites are closely monitored by law enforcement agencies, and the organizers don’t want to expose their botnets. However, we did come across services offering attacks on government resources as a separate item in the price list.
“The price may change if the resource has political status” reads a resource promoting DDoS attacks
Interestingly, some criminals see nothing wrong with providing protection from DDoS along with their DDoS attack services.
Some services offering DDoS attacks may also offer protection from such attacksPricing: a “cloud” example
Let’s consider a DNS amplification attack scenario. This type of attack involves the sending of a specially formed request (for example, 100 bytes in volume) to a vulnerable DNS server that responds to the “sender” (i.e. the victim) with a larger volume (kilobyte) of data. The botnet may consist of tens or even hundreds of such servers or the resources of a public cloud service provider. Add in public web load testing services that can be used to carry out a SaaS amplification attack, and we end up with a fairly heavy “sledgehammer”.
DDoS = Cloud + DNS Amplification + SaaS Amplification
The cost of this service depends on the cost of the provider’s resources. Let’s take Amazon EC2 as an example – the price for a virtual dedicated server with minimal configuration (for a DDoS attack, the configuration of the infected workstation is not as important as its bandwidth connection) is about $0.0065 per hour. Therefore, 50 virtual servers for the organization of a low-powered DDoS attack on an online store will cost cybercriminals $0.325 per hour. Taking into account additional expenses (for example, a SIM card to register an account and adding a credit card to it), an hour-long DDoS attack using a cloud service will cost the criminals about $4.
Price list for popular cloud service providers
This means the actual cost of an attack using a botnet of 1000 workstations can amount to $7 per hour. The asking prices for the services we managed to find were, on average, $25 per hour, meaning the cybercriminals organizing DDoS attack are making a profit of about $18 for every hour of an attack.Conclusion
The clients of these services understand perfectly well the benefits of DDoS attacks and how effective they can be. The cost of a five-minute attack on a large online store is about $5. The victim, however, can lose far more because potential customers simply cannot place an order. We can only guess how many customers an online store loses if an attack lasts the whole day.
At the same time, cybercriminals continue to actively seek new and cheaper ways to organize botnets. In this regard, the Internet of things makes life easier for them. One of the current trends is the infection of IoT devices (CCTV cameras, DVR-systems, “smart” household appliances, etc.) and their subsequent use in DDoS attacks. And while vulnerable IoT devices exist, cybercriminals are able to exploit them.
It should be noted that DDoS attacks and, in particular, ransomware DDoS have already turned into a high-margin business: the profitability of one attack can exceed 95%. And the fact that the owners of online sites are often willing to pay a ransom without even checking whether the attackers can actually carry out an attack (something that other fraudsters have already picked up on) adds even more fuel to the fire. All the above suggests that the average cost of DDoS attacks in the near future will only fall, while their frequency will increase.
The planning for Kaspersky Lab Security Analyst Summit (SAS 2017) is nearing completion and we have a small number of invitations available for malware researchers, law enforcement officials, incident responders and professionals involved in the fight against cybercrime.
If you’ve never been to SAS, ask around. You really are missing out on the best security conference in the industry – and event where the best connections are made, high-quality discoveries are shared in a fun, casual atmosphere.
This year, the conference will be in beautiful St Maarten at the Westin Dawn Beach Resort & Spa. The agenda is now live with a wide range of quality keynotes and presentations. If you still haven’t made up your mind, here are the top ten reasons to make a last-minute decision to join us in St Maarten.
Mark Dowd’s first ever conference keynote: Mark Dowd, of ISS X-Force fame, is globally respected for his work hacking – and fixing – some of the biggest software vulnerabilities. He has literally written the book on software security assessment and now focuses his efforts on breaking Apple’s iOS to look for security holes. At SAS 2017, Dowd’s keynote will focus on the memory corruption safety dance.
The Internet of Things (IoT) is everywhere around us, presenting amazing gadgets like drones and productivity devices. It also introduces a wide range of vulnerabilities. The agenda is filled with presentations on these weaknesses and promises a straightforward discussion on where the industry needs to go to protect the world from attacks that are inevitable.
The SAS conference is renowned for uncompromising APT revelations and 2017 promises een more. Kris McConkehy from PwC will reveal technical talk on a seven-year malicious campaign; BAE Systems and Kaspersky Lab with a story about chasing bad guys from Bangladesh to Costa Rica (hint: SWIFT); Researchers from Mandiant will discuss major campaigns against the hospitality and gaming industries; Lookout Security will provide new information on a nation-state backed mobile espionage case.
Much like IoT issues, the world is moving swiftly to smart city deployments. These manage transportation sectors, traffic lights, water meters and a range of technologies to increase efficiency and cut costs. At SAS 2017, Smart Cities will take center stage with a highly anticipated talk on the security problems with the deployment on a smart city municipal drone programs. SAS 2017 participants will also learn how to build and run an IoT honeypot for researching attacks and evaluate first results of IoT tracking project.
Security experts willpresent a cheap and simple hardware design that can empty one of the most popular ATM models in the world; others will talk about criminal gangstargeting banks and Apple and the hijacking of a major financial institution.
We are in the midst of a ransomware epidemic but did you know there is a new trend emerging regarding ransomware in targeted attacks? Think APTs merging with ransomware cybercriminals and you will understand why this is an incredibly important topic. Security experts from Google will also talk about how to harden Android against ransomware).
If you think the debate on vulnerability disclosure is complete, think again. SAS 2017 will present an entire session focused on this evergreen issue with some of the biggest names joining us to share their expertise – Katie Moussouris, Alex Rice, David Jacoby, Kymberlee Price and Cesar Cerrudo. There may even be an interesting news announcement
This year we found a new family of ransomware used in targeted attacks against organizations. After penetrating an organization’s network the threat actors used the PsExec tool to install ransomware on all endpoints and servers in the organization. The next interesting fact about this ransomware is that the threat actors decided to use the well-known Petya ransomware to encrypt user data. As you may know, this family of ransomware has a RaaS model, but the threat actor decided not to use this ability. To get a workable version of the ransomware, the group behind PetrWrap created a special module that patches the original Petya ransomware “on the fly”. This is what makes this new malware so unique.Tech details
The PetrWrap Trojan is written in C and compiled in MS Visual Studio. It carries a sample of the Petya ransomware v3 inside its data section and uses Petya to infect the victim’s machine. What’s more, PetrWrap implements its own cryptographic routines and modifies the code of Petya in runtime to control its execution. This allows the criminals behind PetrWrap to hide the fact that they are using Petya during infection.Modus operandi
After being launched PetrWrap delays its execution (sleeps for 5400 seconds = 1.5 hours). After that it decrypts the main DLL of Petya from its data section and gets ready to call its exported function ZuWQdweafdsg345312. This function normally prepares Petya for further operations and starts the MBR overwrite process. PetrWrap, however, needs to hook a couple of Petya’s functions first, so it replaces the instructions that call Petya’s DllEntryPoint with NOPs (hex bytes 0x90). This prevents Petya from proceeding on its own and allows PetrWrap to make all the necessary computations and preparations before letting it continue.
Main function of PetrWrap
After that PetrWrap makes the necessary cryptographic computations (we’ll discuss them in more detail below), hooks two Petya procedures (which are responsible for the generation of the configuration data, dubbed petya_generate_config, and for the MBR overwrite process, dubbed petya_infect) and then passes the execution to Petya. For more information on what the original Petya was capable of, please see our previous publication.Cryptographic scheme
Normally, Petya generates a 16-byte key and uses the Salsa20 cipher to encrypt the MFT of the NTFS partitions found on local drives. To make decryption possible only by its operators, it uses the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with the curve secp192k1 and a public key is embedded into Petya’s body.
The criminals behind PetrWrap faced a problem: if they used Petya as is, they would be unable to decrypt the victim’s machine because they would need the Petya operators’ private key. So what they decided to do was to completely replace the ECDH part of Petya with their own independent implementation and use their own private and public keys.
PetrWrap implementation uses cryptographic routines from OpenSSL (whereas Petya used the mbedtls library) and proceeds as follows:
- The Trojan contains an embedded public key master_pub (which is a point on the curve prime192v1 which is again different from the one chosen by Petya);
- During each infection PetrWrap generates a new pair of session keys ec_session_priv + ec_session_pub;
- Computes ecdh_shared_digest = SHA512(ECDH(master_pub, ec_session_priv));
- ‘Intercepts’ the salsa key generated by Petya and encrypts it using ecdh_shared_digest (there are a number of semi-useless manipulations which come down to essentially encrypting the salsa key with AES-256 using different parts of ecdh_shared_digest as the key and IV);
- Constructs user_id which is a string representation that contains the encrypted salsa key and the ec_session_pub;
- Passes this user_id to Petya, which uses it as if it was its own data (puts it into the configuration for the bootloader to be shown to the user after the PC reboot).
The ECDH shared key computation implemented in PetrWrapHooked procedures
PetrWrap hooks two procedures in Petya which we will call petya_infect and petya_generate_config and replaces them with its own procedures dubbed wrap_infect and wrap_generate_config.
wrap_infect implements the following functionality:
- saves the salsa key generated by Petya for further use;
- patches the Petya bootloader code and ransom text in order to skip the flashing skull animation and to wipe all mention of Petya in the ransom message;
- passes execution to the original petya_infect procedure.
wrap_generate_config in turn does the following:
- calls the original petya_generate_config procedure;
- generates the user_id string according to the algorithm described in the previous paragraph;
- replaces Petya’s id string with this newly generated user_id.
The screen of the infected machineTechnical summary
As a result of all the manipulations described above, PetrWrap achieves the following goals:
The victim’s machine is locked and the MFT of NTFS partitions is encrypted securely (because Petya v3 which is used in this attack doesn’t have flaws of the earlier versions and implements Salsa20 correctly);
The lockscreen doesn’t show the flashing skull animation and doesn’t contain any mentions of Petya which makes it harder to assess the situation and determine the extent of the caused damage;
The developers of PetrWrap didn’t have to write the low-level bootloader code and risk making mistakes similar to the ones observed in earlier versions of Petya.
Unfortunately, this family of ransomware uses a strong encryption algorithm, meaning a decryption tool is out of the question. However, victims can try restoring files using third-party tools such as R-Studio.Detection
Kaspersky products successfully detect this ransomware as Trojan-Ransom.Win32.PetrWrap and PDM:Trojan.Win32.Generic.Conclusion
Targeted attacks on organizations with the main aim of encrypting data are becoming more popular. The groups using ransomware in their targeted attacks usually try to find vulnerable servers or servers with unprotected RDP access. After penetrating an organization’s network they use special frameworks like Mimikatz to obtain the necessary credentials for installing ransomware throughout the network. To protect against such attacks, organizations need to keep their server software up to date, use secure passwords for remote access systems, install security solutions on their servers and use security solutions with behavioral detection components on their endpoints.
17c25c8a7c141195ee887de905f33d7b – Trojan-Ransom.Win32.PetrWrap.b
Beginning in November 2016, Kaspersky Lab observed a new wave of wiper attacks directed at multiple targets in the Middle East. The malware used in the new attacks was a variant of the infamous Shamoon worm that targeted Saudi Aramco and Rasgas back in 2012.
Dormant for four years, one of the most mysterious wipers in history has returned.
So far, we have observed three waves of attacks of the Shamoon 2.0 malware, activated on 17 November 2016, 29 November 2016 and 23 January 2017.
Also known as Disttrack, Shamoon is a highly destructive malware family that effectively wipes the victim machine. A group known as the Cutting Sword of Justice took credit for the Saudi Aramco attack by posting a Pastebin message on the day of the attack (back in 2012), and justified the attack as a measure against the Saudi monarchy.
The Shamoon 2.0 attacks seen in November 2016 targeted organizations in various critical and economic sectors in Saudi Arabia. Just like the previous variant, the Shamoon 2.0 wiper aims for the mass destruction of systems inside compromised organizations.
The new attacks share many similarities with the 2012 wave and now feature new tools and techniques. During the first stage, the attackers obtain administrator credentials for the victim’s network. Next, they build a custom wiper (Shamoon 2.0) which leverages these credentials to spread widely inside the organization. Finally, on a predefined date, the wiper activates, rendering the infected machines completely inoperable. It should be noted that the final stages of the attacks are completely automated, without the need for communication with the command and control center.
While investigating the Shamoon 2.0 attacks, Kaspersky Lab also discovered a previously unknown wiper malware which appears to be targeting organizations in Saudi Arabia. We’re calling this new wiper StoneDrill. StoneDrill has several “style” similarities to Shamoon, with multiple interesting factors and techniques to allow for the better evasion of detection. In addition to suspected Saudi targets, one victim of StoneDrill was observed on the Kaspersky Security Network (KSN) in Europe. This makes us believe the threat actor behind StoneDrill is expanding its wiping operations from the Middle East to Europe.
To summarize some of the characteristics of the new wiper attacks, for both Shamoon and StoneDrill:
- Shamoon 2.0 includes a fully functional ransomware module, in addition to its common wiping functionality.
- Shamoon 2.0 has both 32-bit and 64-bit components.
- The Shamoon samples we analyzed in January 2017 do not implement any command and control (C&C) communication; previous ones included a basic C&C functionality that referenced local servers in the victim’s network.
- StoneDrill makes heavy use of evasion techniques to avoid sandbox execution.
- While Shamoon embeds Arabic-Yemen resource language sections, StoneDrill embeds mostly Persian resource language sections. Of course, we do not exclude the possibility of false flags.
- StoneDrill does not use drivers during deployment (unlike Shamoon) but relies on memory injection of the wiping module into the victim’s preferred browser.
- Several similarities exist between Shamoon and StoneDrill.
- Multiple similarities were found between StoneDrill and previously analysed NewsBeef attacks.
We are releasing a full technical report that provides new insights into the Shamoon 2.0 and StoneDrill attacks, including:
- The discovery techniques and strategies we used for Shamoon and StoneDrill.
- Details on the ransomware functionality found in Shamoon 2.0. This functionality is currently inactive but could be used in future attacks.
- Details on the newly found StoneDrill functions, including its destructive capabilities (even with limited user privileges).
- Details on the similarities between malware styles and malware components’ source code found in Shamoon, StoneDrill and NewsBeef.
Our discovery of StoneDrill provides another dimension to the existing wave of wiper attacks against Saudi organizations that started with Shamoon 2.0 in November 2016. Compared to the new Shamoon 2.0 variants, the most significant difference is the lack of a disk driver used for direct access during the destructive step. Nevertheless, one does not necessarily need raw disk access to perform destructive functions at file level, which the malware implements quite successfully.
Of course, one of the most important questions here is the connection between Shamoon and StoneDrill. Both wipers appear to have been used against Saudi organizations during a similar timeframe of October-November 2016. Several theories are possible here:
- StoneDrill is a less-used wiper tool, deployed in certain situations by the same Shamoon group.
- StoneDrill and Shamoon are used by different groups which are aligned in their interests.
- StoneDrill and Shamoon are used by two different groups which have no connection to each other and just happen to target Saudi organizations at the same time.
Taking all factors into account, our opinion is that the most likely theory is the second.
Additionally, StoneDrill appears to be connected with previously reported NewsBeef activity (LINK TO https://securelist.com/blog/software/74503/freezer-paper-around-free-meat/), which continues to target Saudi organizations. From this point of view, NewsBeef and StoneDrill appear to be continuously focused on targeting Saudi interests, while Shamoon is a flashy, come-and-go high impact tool.
In terms of attribution, while Shamoon embeds Arabic-Yemen resource language sections, StoneDrill embeds mostly Persian resource language sections. Geopolitical analysts would be quick to point out that Iran and Yemen are both players in the Iran-Saudi Arabia proxy conflict. Of course, we do not exclude the possibility of false flags.
Finally, many unanswered question remain in regards to StoneDrill and NewsBeef. The discovery of the StoneDrill wiper in Europe is a significant sign that the group is expanding its destructive attacks outside the Middle East. The target for the attack appears to be a large corporation with a wide area of activity in the petro-chemical sector, with no apparent connection or interest in Saudi Arabia.
As usual, we will continue to monitor the Shamoon, StoneDrill and NewsBeef attacks.
A presentation about StoneDrill will be given at the Kaspersky Security Analyst Summit Conference in April 2-6, 2017.
Kaspersky Lab products detect the Shamoon and StoneDrill samples as: