Smart cities must be cyber‑smart cities

As cities turn to IoT to address long-standing urban problems, what are the risks of leaving cybersecurity behind at the planning phase?

You’ve probably heard the term “smart cities” – that is, the idea that extensive use of Information and Communications Technology (ICT) to monitor energy, utilities and transportation infrastructure can lead to cost savings, reduction of environmental impact and faster fault resolution.

The benefits are obvious. If a street lamp fails, and can tell you so, you can replace it more quickly. If you can control traffic more efficiently, you’ll reduce smog and noise, and reduce overall journey times. If you can tie AC/heating to ambient temperature in a fine-grained way, you can reduce power consumption and wastage. If you can track traffic in real time, you can plan the best routes for emergency response vehicles.

Most national governments have committed to the Paris Agreement, and therefore need to reach targets for reduced carbon emissions. These targets necessarily pass down to the regional and municipal levels, and the implementation of smart technologies in urban areas has a large part to play in achieving those goals. However, where there are complex, interconnected, computer-controlled networks of thousands of Internet of Things (IoT) sensors and devices, all sorts of alarm bells start to ring in the minds of cybersecurity practitioners.

ESET researchers have analyzed malware (e.g. here and here) that was most probably used in several attacks against the energy industry and ultimately caused power outages. This sort of disruption has major effects on people’s lives, and intermittent or unreliable power does not take long to cause problems. Foods and medicines start to decay rapidly as refrigeration and freezers start to heat up. Hospitals must reduce power consumption to the essentials. Petrol pumps don’t work (nor for that matter do smart vehicle charging stations), traffic light systems go down, buildings start to over-heat, or over-cool. Street lighting stops working. Electronic payment doesn’t work, wages may not be paid, ATMs don’t dispense cash. You can’t recharge your phone or your laptop. Your insulin pump won’t charge, your CPAP (continuous positive airway pressure) device won’t work, nor will your remote monitoring systems, your security cameras – or your coffee machine! It doesn’t take much to understand that in these circumstances chaos quickly ensues.

We can also imagine more subtle attacks than total electricity outages. There have been at least two major cases of illicit cryptocurrency-mining software on compromised nuclear power plant control systems. Cryptocurrency mining is incredibly power-intensive, and therefore has a high environmental impact – in addition to the cost and the potential to cause power distribution problems as described above. It’s not just companies that are affected by such attacks. In many (most?) cases, IoT devices are not well secured, and their vulnerabilities can lead to an attack where there is little user-initiated mitigation possible. Last year a large-scale operation was discovered using home internet routers to mine cryptocurrency. Where there is money to be made, and easily – given the vulnerability of the systems – there will be criminal exploitation.

Smart meters are a boon to utility companies as well as consumers and businesses, allowing precise monitoring of utility consumption, but their compromise can enable the theft of power/gas/water. Perhaps worse – such meters can also indicate how much generated power is being put into the grid (think rooftop solar) and the rest of the grid depends on that being accurate to do proper load balancing and generation. As is often the case with failures of security, it’s the unforeseen events that can have the most devastating results.

The European Union (EU) has been very active in implementing smart city technologies, among other IoT-driven projects, with many set up under the aegis of its research and innovation program called Horizon 2020. These projects vary in scope, but many have vast implications for the sectors they affect – smart cites and society, agriculture, healthcare, ocean and water management, food, manufacturing, and many other aspects of lives.

Some of these projects are governed by Mission Boards that serve to guide and advise on the projects’ implementation. (Full disclosure: I was one of 550 applicants to the Mission Board for Climate-Neutral and Smart Cities, but did not obtain a seat, of which there were 15.)

The boards are made up of members working in a diverse range of disciplines, and we should hope that cybersecurity will be foremost in their thoughts, although it is scarcely mentioned in the briefs for the boards.

When all is said and done, there will be tremendous benefits in implementing technologies that can improve lives and reduce environmental impact. On the other hand, we should never forget the risks that come with failing to consider the security of those technologies.

23 Oct 2019 – 11:30AM

NordVPN reveals breach at datacenter provider

The company says that the incident, going back to March 2018, affected only 1 out of its 3,000 servers

The well-known virtual private network (VPN) provider NordVPN admitted to a breach on Tuesday that had occurred at one of the facilities from which the company rents its servers.

The bad actors exploited an insecure remote management system left by the unnamed Finland-based datacenter provider – with NordVPN saying that it wasn’t even aware of such a system being in use. The incident goes back to March 2018 and NordVPN said it had learned about it “a few months ago”. The company also gave assurances that the server in question did not contain any user activity logs and no user credentials were intercepted.

Nevertheless, the incident compromised a now-expired TLS key. NordVPN claims that there is no conceivable way the key could be used to decrypt VPN traffic on other servers operated by the company and further attempted to tone down the concerns:

“On the same note, the only possible way to abuse website traffic was by performing a personalized and complicated MitM [man-in-the-middle] attack to intercept a single connection that tried to access,” said the company.

NordVPN also claims that immediately after the incident was discovered they conducted a thorough audit of the whole infrastructure to investigate if there were any other weak points that could be exploited. The contract with the Finnish datacenter was terminated. The reason stated for the late disclosure of the breach is the infrastructure audit which, according to the company, took a longer amount of time due to the sheer number of servers maintained by the service.

NordVPN said it took steps to fix the problem, by speeding up the encryption of their servers and creating a process of moving all their servers to RAM, which is expected to be concluded some time next year. Additional security measures are being put in place. Another audit is being conducted, a bug bounty program is being prepared and data centers will have to meet stricter requirements for cooperation, said the company.

22 Oct 2019 – 04:16PM

Winnti Group’s skip‑2.0: A Microsoft SQL Server backdoor

Notorious cyberespionage group debases MSSQL

For a while, ESET researchers have been tracking the activities of the Winnti Group, active since at least 2012 and responsible for high-profile supply-chain attacks against the video game and software industry. Recently, we discovered a previously undocumented backdoor targeting Microsoft SQL (MSSQL) that allows attackers to maintain a very discreet foothold inside compromised organizations. This backdoor bears multiple similarities to the PortReuse backdoor, another tool used by the Winnti Group that was first documented by ESET in October 2019, such as the use of the same custom packer and VMProtected launcher, which is why we attribute this backdoor to the Winnti Group.

Earlier this year, we received a sample of this new backdoor called skip-2.0 by its authors and part of the Winnti Group’s arsenal. This backdoor targets MSSQL Server 11 and 12, allowing the attacker to connect stealthily to any MSSQL account by using a magic password – while automatically hiding these connections from the logs. Such a backdoor could allow an attacker to stealthily copy, modify or delete database content. This could be used, for example, to manipulate in-game currencies for financial gain. In-game currency database manipulations by Winnti operators have already been reported. To the best of our knowledge, skip-2.0 is the first MSSQL Server backdoor to be documented publicly. Note that even though MSSQL Server 11 and 12 are not the most recent versions (released in 2012 and 2014, respectively), they are the most commonly used ones according to Censys’s data.

We recently published a white paper updating our understanding of the arsenal of the Winnti Group, and that exposed a previously undocumented backdoor of theirs called PortReuse. It uses an identical packer to that used with the payload embedded in compromised video games uncovered by ESET in March 2019. The VMProtected launcher that drops the PortReuse backdoor was also found being used to launch recent ShadowPad versions. In that context, we were able to find a new tool called skip.2-0 by its developer. It uses the same VMProtected launcher as well as Winnti Group’s custom packer and exhibits multiple similarities with other samples from the Winnti Group’s toolset. This leads us to ascribe skip-2.0 to that toolset also.

This article will focus on the technical details and functionality of this MSSQL Server backdoor, as well as on exposing the technical similarities of skip.2-0 with the Winnti Group’s known arsenal – in particular, with the PortReuse backdoor and ShadowPad. A note on the reasons why we chose the “Winnti Group” naming can be found on our white paper.

We found skip-2.0 while looking for VMProtected launchers, for which the payload is usually either PortReuse or ShadowPad.

Embedded payload

As with the encrypted PortReuse and ShadowPad payloads, skip-2.0 is embedded in the VMProtected launcher’s overlay, as shown in Figure 1:

Figure 1. VMProtected launcher’s headers. The payload is embedded in the PE overlay.


The payload encryption is identical to that used in the other VMProtected launchers. It is RC5-encrypted with a key derived from the VolumeID and the string [email protected]!rCto R$. – as described in our previous white paper on the Winnti Group arsenal.


As in the case of PortReuse and ShadowPad, the launcher probably persists by exploiting a DLL hijacking vulnerability by being installed at C:WindowsSystem32TSVIPSrv.DLL. This results in the DLL being loaded by the standard Windows SessionEnv service at system startup.

Once decrypted the embedded payload is actually Winnti Group’s custom packer. This packer is the same shellcode that was documented in our previous article and white paper. It is used to pack the PortReuse backdoor as well as the payload embedded in the compromised video games.

Packer configuration

As described in our previous article, the packer configuration contains the decryption key of the packed binary as well as its original filename, its size and the execution type (EXE or DLL). The payload’s packer configuration is shown in Table 1.

Parent SHA-1 Payload SHA-1 RC4 key Filename Launch type
9aafe81d07b3e5bb282608f0a2a4656eb485b7c9 a2571946ab181657eb825cde07188e8bcd689575 163716559 Inner-Loader.dll 2

Table 1. Payload’s packer configuration

One can see from the packer configuration that the payload is called Inner-Loader. Inner-Loader is the name of an injector that is the part of the Winnti Group’s arsenal used to inject the PortReuse backdoor into processes listening on a particular port, as described in our previous publication. Beyond that identical name, by analyzing this payload it appears that it is another variant of the Inner-Loader injector.

This variant of Inner-Loader, instead of looking for a process listening on a particular port, as in the case when injecting the PortReuse backdoor, looks for a process called sqlserv.exe, which is the conventional process name of MSSQL Server. If found, Inner-Loader then injects a payload into this process. This payload is also packed with the custom packer – the packer configuration of that payload is shown in Table 2.

Parent SHA-1 Payload SHA-1 RC4 key Filename Launch type
60b9428d00be5ce562ff3d888441220290a6dac7 923567961 skip-2.0.dll 2

Table 2. Packer configuration of the payload embedded in Inner-Loader

The original filename of this injected payload is skip-2.0.dll.

After having been injected and launched by Inner-Loader, skip-2.0 first checks whether it is executing within an sqlserv.exe process and if so, retrieves a handle to sqllang.dll, which is loaded by sqlserv.exe. It then proceeds to find and hook multiple functions from that DLL. Figure 2 depicts the skip-2.0 chain of compromise.

Figure 2. skip-2.0 unpacking and injection

Hooking sqllang.dll

The hooking procedure used by skip-2.0 is very similar to the one used by NetAgent, the PortReuse module responsible for installing the networking hook. This hooking library is based on the distorm open source disassembler that is used by multiple open source hooking frameworks. In particular, a disassembling library is needed to correctly compute the size of the instructions to be hooked. One can see in Figure 3 that the hooking procedure used by NetAgent and skip-2.0 are almost identical.

Figure 3. Hex-Rays output comparison between the NetAgent (left) and skip-2.0 (right) hooking procedures

There is one notable difference, which is the fact that the hooking function from skip-2.0 takes the address of the hook to be installed as an argument, while for NetAgent, the address of the hook to install is hardcoded. This is due to the fact that skip-2.0 has to hook multiple functions in sqllang.dll to operate properly, while NetAgent only targets a single function.

To locate each sqllang.dll function to be hooked, skip-2.0 first retrieves the size of the DLL once loaded in memory (i.e. its virtual size) by parsing its PE headers. Then an array of bytes to be matched within sqllang.dll is initialized as shown in Figure 4. Once the address of the first occurrence matching the byte array is found, the hook is installed using the procedure shown in Figure 3.

Figure 4. Hex-Rays output of the procedure initializing the byte array to match in sqllang.dll

The success of the hook installation is then logged in cleartext in a log file located at the hardcoded path C:WindowsTempTS_2CE1.tmp and shown in Figure 5.

Figure 5. Log generated during hooks installation

Should the targeted function not be found, the hook installer searches for a fallback function, with a different set of byte patterns.

Matching a sequence of bytes to locate the address of the targeted function instead of using a static offset, plus using a fallback sequence of bytes, allows skip-2.0 to be more resilient to MSSQL updates and to potentially target multiple sqllang.dll updates.

One password to rule them all

The functions targeted by skip-2.0 are related to authentication and event logging. The targeted functions include:

  • CPwdPolicyManager::ValidatePwdForLogin
  • CSECAuthenticate::AuthenticateLoginIdentity
  • ReportLoginSuccess
  • IssueLoginSuccessReport
  • FExecuteLogonTriggers
  • XeSqlPkg::sql_statement_completed::Publish
  • XeSqlPkg::sql_batch_completed::Publish
  • SecAuditPkg::audit_event::Publish
  • XeSqlPkg::login::Publish
  • XeSqlPkg::ual_instrument_called::Publish

The most interesting function is the first one (CPwdPolicyManager::ValidatePwdForLogin), which is responsible for validating the password provided for a given user. This function’s hook checks whether the password provided by the user matches the magic password, in that case, the original function will not be called and the hook will return 0, allowing the connection even though the correct password was not provided. A global flag is then set that will be checked by the other hooked functions responsible for event logging. The corresponding decompiled procedure is shown in Figure 6. In the case where this global flag is set, the hooked logging functions will silently return without calling their corresponding, original functions, so the action will not be logged. In the case where a different password is provided, the original function is called.

Figure 6. Hex-Rays output of the procedure responsible for matching the password provided at login with the hardcoded string

A similar backdooring technique, based on hardcoded passwords, was used with SSH backdoors previously discovered by ESET. The difference here is that skip-2.0 is installed in-memory, while in the case of the SSH backdoors the sshd executable was modified prior to execution.

Additionally, CSECAuthenticate::AuthenticateLoginIdentity will be called from within its hook code but the hook will always return 0. The ReportLoginSucess and IssueLoginSuccessReport hooks will not call the original functions if the magic password was used to log in. The same behavior is applied to FEExecuteLogonTriggers. Other logging functions such as XeSqlPkg::sql_statement_completed::Publish or XeSqlPkg::sql_batch_completed::Publish will also be disabled in the case where the user logged in with the magic password. Multiple audit events are disabled as well, including SecAuditPkg::audit_event::Publish, XeSqlPkg::login::Publish and XeSqlPkg::ual_instrument_called::Publish.

This series of hooks allows the attacker not only to gain persistence in the victim’s MSSQL Server through the use of a special password, but also to remain undetected thanks to the multiple log and event publishing mechanisms that are disabled when that password is used.

We tested skip-2.0 against multiple MSSQL Server versions and found that we were able to login successfully using the special password with MSSQL Server 11 and 12. To check whether a particular sqllang.dll version is targeted by skip-2.0 (i.e., that matches the byte patterns), we created a YARA rule, which can be found in our GitHub repository.

We observed multiple similarities between skip-2.0 and other tools from the Winnti Group’s arsenal. Its VMProtected launcher, custom packer, Inner-Loader injector and hooking framework are part of the already known toolset of the Winnti Group. This leads us to think that skip-2.0 is also part of that toolset.

The skip-2.0 backdoor is an interesting addition to the Winnti Group’s arsenal, sharing a great deal of similarities with the group’s already known toolset, and allowing the attacker to achieve persistence on an MSSQL Server. Considering that administrative privileges are required for installing the hooks, skip-2.0 must be used on already compromised MSSQL Servers to achieve persistence and stealthiness.

We will continue to monitor new activities of the Winnti Group and will publish relevant information on our blog. For any inquiries, contact us at [email protected].

Component SHA-1 ESET detection name
VMP Loader 18E4FEB988CB95D71D81E1964AA6280E22361B9F
Inner-Loader injector A2571946AB181657EB825CDE07188E8BCD689575 Win64/Injector.BS
skip-2.0 60B9428D00BE5CE562FF3D888441220290A6DAC7 Win32/Agent.SOK
Known targeted sqllang.dll files (non-exhaustive list) 4396D3C904CD340984D474065959E8DD11915444

MITRE ATT&CK techniques

Tactic ID Name Description
Execution T1035 Service Execution skip-2.0 is started with the SessionEnv service
Persistence T1038 DLL Search Order Hijacking skip-2.0 probably uses a DLL hijacking technique against the SessionEnv service
T1179 Hooking skip-2.0 hooks multiple functions in sqllang.dll service to bypass authentication and maintain stealth
Defense Evasion T1054 Indicator Blocking skip-2.0 blocks event logging
T1045 Software Packing skip.2-0 and Inner-Loader are packed using Winnti’s custom packer. Further, the launcher is VMProtected.
Discovery T1057 Process Discovery Inner-Loader lists running processes in order to find the process running MSSQL Server
Impact T1485 Data Destruction skip-2.0 allows unauthorized access to MSSQL databases, allowing data destruction or tampering
T1494 Runtime Data Manipulation skip-2.0 manipulates event logging at runtime
T1492 Stored Data Manipulation skip-2.0 allows unauthorized access to MSSQL databases, allowing manipulation of stored data

21 Oct 2019 – 11:30AM

Week in security with Tony Anscombe

This week, ESET experts described recent shenanigans of The Dukes and the Winnti Group, vulnerabilities in Amazon Echo and Kindle, and a fake Tor Browser stealing cryptocurrency

This week, ESET experts revealed how The Dukes, the APT group suspected of breaching the DNC several years ago, has been busy compromising government targets while staying under the radar for years. ESET researchers also uncovered that Amazon Echo and Kindle were vulnerable to Wi-Fi vulnerabilities known as KRACK while another team described updates to the malware arsenal and campaigns of the Winnti Group. In yet another major research effort, ESET experts discovered a trojanized Tor Browser distributed by cybercriminals to steal bitcoins from darknet market buyers. For more information, go to

Fleecing the onion: Darknet shoppers swindled out of bitcoins via trojanized Tor Browser

ESET researchers discover a trojanized Tor Browser distributed by cybercriminals to steal bitcoins from darknet market buyers

Utilizing a trojanized version of an official Tor Browser package, the cybercriminals behind this campaign have been very successful – so far their accounts have had more than 500,000 views and they were able to steal US$40,000+ in bitcoins.

This newly discovered trojanized Tor Browser has been spreading using two websites that claimed that they distribute the official Russian language version of the Tor Browser. The first such website displays a message in Russian claiming that the visitor has an outdated Tor Browser. The message is displayed even if the visitor had the most up-to-date Tor Browser version.

Figure 1. Fake outdated browser message displayed at torproect[.]org

Translated to English:

Your anonymity is in danger!
WARNING: Your Tor Browser is outdated
Click the button “Update”

On clicking the “Update Tor Browser” button, the visitor is redirected to a second website with the possibility of downloading a Windows installer. There are no signs that the same website has distributed Linux, macOS or mobile versions.

Figure 2. Fake Tor Browser website with download option

Both these domains – tor-browser[.]org and torproect[.]org – were created in 2014. The malicious domain torproect[.]org domain is very similar to the real; it is just missing one letter. For Russian-speaking victims, the missing letter might raise no suspicion due to the fact that “torproect” looks like a transliteration from the Cyrillic. However, it does not look like criminals relied on typosquatting, because they promoted these two websites on various resources.

In 2017 and early 2018 cybercriminals promoted the webpages of the trojanized Tor Browser using spam messages on various Russian forums. These messages contain various topics, including darknet markets, cryptocurrencies, internet privacy and censorship bypass. Specifically, some of these messages mention Roskomnadzor, a Russian government entity for censorship in media and telecommunications.

Figure 3. Example of spam message promoting tor-browser[.]org

Figure 4. Example of spam message promoting torproect[.]org

In April and March 2018, the criminals started to use the web service to promote both domains related to the fake Tor Browser webpage. Specifically, they created four accounts and generated a lot of pastes optimized for search engines to rank them high for words that cover topics like drugs, cryptocurrency, censorship bypass, and the names of Russian politicians.

The idea behind this is that a potential victim would perform an online search for specific keywords and at some point visit a generated paste. Each such paste has a header that promotes the fake website.

Figure 5. The header of a paste that promotes fake Tor Browser websites

This translates to English:

BRO, download Tor Browser so the cops won’t watch you.
Regular browsers show what you are watching, even through proxies and VPN plug-ins.
Tor encrypts all traffic and passes it through random servers from around the world.
It is more reliable than VPN or proxy and bypasses all Roskomnadzor censorship.
Here is official Tor Browser website:
Tor Browser with anti-captcha:
Save the link

The criminals claim that this version of the Tor Browser has anti-captcha capability, but in fact this is not true.

Figure 6. An example paste with keywords related to the Tor Browser

All of the pastes from the four different accounts were viewed more than 500,000 times. However, it’s not possible for us to say how many viewers actually visited the websites and downloaded the trojanized version of the Tor Browser.

This trojanized Tor Browser is a fully functional application. In fact, it is based on Tor Browser 7.5, which was released in January 2018. Thus, non-technically-savvy people probably won’t notice any difference between the original version and the trojanized one.

No changes were made to source code of the Tor Browser; all Windows binaries are exactly the same as in the original version. However, these criminals changed the default browser settings and some of the extensions.

Figure 7. The modified settings of the trojanized Tor Browser in extension-overrides.js

The criminals want to prevent victims from updating the trojanized Tor version to a newer version, because in this case it will be updated to a non-trojanized, legitimate version. That’s why they disabled all kinds of updates in the settings, and even renamed the updater tool from updater.exe to updater.exe0.

In addition to the changed update settings, the criminals changed the default User-Agent to the unique hardcoded value:

Mozilla/5.0 (Windows NT 6.1; rv:77777.0) Gecko/20100101 Firefox/52.0

All trojanized Tor Browser victims will use the same User-Agent; thus it can be used as a fingerprint by the criminals to detect, on the server-side, whether the victim is using this trojanized version.

The most important change is to the xpinstall.signatures.required settings, which disable a digital signature check for installed Tor Browser add-ons. Therefore, the attackers can modify any add-on and it will be loaded by the browser without any complaint about it failing its digital signature check.

Furthermore, the criminals modified the HTTPS Everywhere add-on included with the browser, specifically its manifest.json file. The modification adds a content script (script.js) that will be executed on load in the context of every webpage.

Figure 8. Difference between original manifest.json (left) and modified (right)

This injected script notifies a C&C server about the current webpage address and downloads a JavaScript payload that will be executed in the context of the current page. The C&C server is located on an onion domain, which means it is accessible only through Tor.

Figure 9. The injected script executed in the context of every webpage

As the criminals behind this campaign know what website the victim is currently visiting, they could serve different JavaScript payloads for different websites. However, that is not the case here: during our research, the JavaScript payload was always the same for all pages we visited.

The JavaScript payload works as a standard webinject, which means that it can interact with the website content and perform specific actions. For example, it can do a form grabbing, scrape, hide or inject content of a visited page, display fake messages, etc.

However, it should be noted that the de-anonymization of a victim is a hard task because the JavaScript payload is running in the context of the Tor Browser and does not have access to the real IP address or other physical characteristics of the victim machine.

The only JavaScript payload we have seen targets three of the largest Russian-speaking darknet markets. This payload attempts to alter QIWI (a popular Russian money transfer service) or bitcoin wallets located on pages of these markets.

Figure 10. The part of the JavaScript payload designed to alter cryptocurrency wallets

Once a victim visits their profile page in order to add funds to the account directly using bitcoin payment, the trojanized Tor Browser automatically swaps the original address to the address controlled by criminals.

Figure 11. A darknet market profile page with altered bitcoin address

During our investigation we identified three bitcoin wallets that have been used in this campaign since 2017. Each such wallet contains relatively large numbers of small transactions; this suggests that these wallets were indeed used by the trojanized Tor Browser.

Figure 12. Number of transactions and received bitcoin for one of the criminals’ wallets

As of this writing, the total amount of received funds for all three wallets is 4.8 bitcoin, which corresponds to over US$40,000. It should be noted that the real amount of stolen money is higher because the trojanized Tor Browser also alters QIWI wallets.

This trojanized Tor Browser is a non-typical form of malware, designed to steal digital currency from visitors to darknet markets. Criminals didn’t modify binary components of the Tor Browser; instead, they introduced changes to settings and the HTTPS Everywhere extension. This has allowed them to steal digital money, unnoticed, for years.






Tactic ID Name Description
Execution T1204 User Execution The trojanized Tor Browser relies on the victim to execute the initial infiltration.
Persistence T1176 Browser Extensions The trojanized Tor Browser contains a modified HTTPS Everywhere extension.
Collection T1185 Man in the Browser The trojanized Tor Browser is able to change content, modify behavior, and intercept information using man-in-the- browser techniques.
Command and Control T1188 Multi-hop Proxy The trojanized Tor Browser uses Tor onion service in order to download its JavaScript payload.
T1079 Multilayer Encryption The trojanized Tor Browser uses Tor onion service in order to download its JavaScript payload.
Impact T1494 Runtime Data Manipulation The trojanized Tor Browser alters bitcoin and QIWI wallets on darknet market webpages.

18 Oct 2019 – 11:30AM

What was wrong with Alexa? How Amazon Echo and Kindle got KRACKed

ESET Smart Home Research Team uncovers Echo, Kindle versions vulnerable to 2017 Wi-Fi vulnerabilities

In recent years, hundreds of millions of homes have become “smarter” and internet-enabled using one of the popular home assistant devices. Despite the efforts of some vendors to develop these devices with security in mind, ESET Smart Home Research Team discovered that even the popular Amazon Echo – the original hardware of Amazon Alexa – was open to Key Reinstallation Attack (KRACK) vulnerabilities. This was also the case for at least one generation of the widely used Amazon Kindle e-readers.

All identified flaws were reported to – and subsequently patched by – Amazon’s security team.

In 2017, two Belgian researchers, Mathy Vanhoef and Frank Piessens, made a surprising announcement. They had found serious weaknesses in the WPA2 standard, a protocol that at that time was securing virtually all modern Wi-Fi networks. As described in their paper, KRACK attacks were mostly aimed against the four-way handshake – a mechanism used for two purposes: confirming that both the client and access point possess the correct credentials, and negotiation of the key used for encryption of the traffic.

Vanhoef’s team found that an adversary could trick a victim device into reinitializing the pair-wise key used in the current session (this is not the Wi-Fi password) by crafting and replaying cryptographic handshake messages. By exploiting this flaw, an attacker is able to gradually reconstruct the encryption XOR stream and then sniff the victim’s network traffic.

Even two years later, many Wi-Fi enabled devices are still vulnerable to KRACK attacks. As demonstrated by the ESET Smart Home Research Team, this included multiple Amazon devices. With Amazon having sold tens of millions Amazon Echos in the US alone, and tens of millions of Amazon Kindles, this posed a far-reaching security risk.

As part of our research, we tested the 1st generation of Amazon Echo (original hardware of Amazon Alexa) and 8th generation of Amazon Kindle. Our experiments mostly focused on the devices’ resilience against the various KRACK attacks, utilizing the scripts made available by Vanhoef’s team.

The Echo 1st  generation and Amazon Kindle 8th generation devices were found to be vulnerable to two KRACK vulnerabilities. Using Vanhoef’s scripts, we were able to replicate the reinstallation of the pairwise encryption key (PTK-TK) in the four-way handshake (CVE-2017-13077) and reinstallation of the group key (GTK) in the four-way handshake (CVE-2017-13078).

Figure 1. Amazon Echo 1st generation reinstalls encryption keys (CVE-2017-13077)

These vulnerabilities are quite severe as they allow an attacker to:

  • replay old packets to execute a DoS attack, disrupt network communication or replay attack
  • decrypt any data or information transmited by the victim
  • depending on the network configuration: forge data packets, cause the device to dismiss packets or even inject new packets
  • intercept sensitive information such as passwords or session cookies

Amazon home assistant was also susceptible to yet another network vulnerability, unrelated to KRACK: a broadcast replay attack – a network attack in which a valid broadcast transmission is fraudulently repeated and then accepted by the targeted device. It is a low tier attack that an adversary can abuse to launch a denial of service (DoS) attack or collecting packets for future cryptoanalysis or brute force attack.

Figure 2. Amazon Echo 1st generation accepting a replayed broadcast message

ESET research reported all identified vulnerabilities in Echo and Kindle to Amazon on October 23rd, 2018 and received acknowledgment of the issue on the same date. On January 8th, 2019 ESET received confirmation that Amazon’s security team had replicated the reported issues, prepared patches and would be distributing them to users in the forthcoming weeks.

To patch CVE-2017-13077 and CVE-2017-13078 vulnerabilities in several million Echo 1st generation and Amazon Kindle 8th generation devices, Amazon issued and distributed a new version of the wpa_supplicant – a software application on the client device responsible for correct authentication to the Wi-Fi network.

The ESET Smart Home Research Team found that Amazon Echo 1st as well as Amazon Kindle 8th generation devices were susceptible to various KRACK attacks. We have reported all the identified issues to the manufacturer for patching.

It should be noted that KRACK attacks – similar to any other attack against Wi-Fi networks – require close proximity to be effective. This means the attacker and victim devices both must be in range of the same Wi-Fi radio network for the compromise to take place.

Attacks against Amazon – and presumably other – devices are also unlikely to significantly affect the security of the information sent over the network. This is thanks to the bulk of the sensitive data being protected by additional security measures above the standard WPA/WPA2 encryption, namely HTTPS using TLS encryption.

The exploits described above affect solely the security of WPA/WPA2. If successful, the effect would be similar to the victim using an unprotected Wi-Fi network. Thus, the practical impact would mostly pertain to data not properly protected by other network layers such as TLS – or when combined with other exploits – and are beyond the scope of this article.

In any case, we advise all Amazon users to verify – via their Echo app and Kindle settings – that they are using the latest Echo and Kindle firmware.

Acknowledgements to ESET Security Awareness Specialist Ondrej Kubovič for his help with this article.

17 Oct 2019 – 11:31AM

Operation Ghost: The Dukes aren’t back – they never left

ESET researchers describe recent activity of the infamous espionage group, the Dukes, including three new malware families

The Dukes (aka APT29 and Cozy Bear) have been in the spotlight after their suspected involvement in the breach of the Democratic National Committee in the run-up to the 2016 US elections. Since then, except for a one-off, suspected comeback in November 2018, with a phishing campaign targeting several US-based organizations, no activity has been confidently attributed to the Dukes. This left us thinking that the group had stopped its activities.

This held true until recent months, when we uncovered three new malware families that we attribute to the Dukes – PolyglotDuke, RegDuke and FatDuke. These new implants were used until very recently, with the latest observed sample being deployed in June 2019. This means the Dukes have been quite active since 2016, developing new implants and compromising high-value targets. We call these newly uncovered Dukes activities, collectively, Operation Ghost.

We believe Operation Ghost started in 2013 and it is still ongoing as of this writing. Our research shows that the Ministries of Foreign Affairs in at least three different countries in Europe are affected by this campaign. We have also discovered an infiltration by the Dukes at the Washington, DC embassy of a European Union country.

One of the first public traces of this campaign is to be found on Reddit in July 2014. Figure 1 shows a message posted by the attackers. The strange string using an unusual character set is the encoded URL of a C&C server used by PolyglotDuke.

Figure 1. Reddit post containing an encoded Command & Control URL

Figure 2 presents the timeline of Operation Ghost. As it is based on ESET telemetry, it might be only a partial view of a broader campaign.

Figure 2. Timeline of Operation Ghost

On one hand, we noticed numerous similarities in the tactics of this campaign to those from previously documented ones, such as the use of:

  • Twitter (and other social websites such as Reddit) to host C&C URLs
  • steganography in images to hide payloads or C&C communications
  • Windows Management Instrumentation (WMI) for persistence

We also noticed important similarities in the targeting:

  • all the known targets are Ministries of Foreign Affairs.
  • known targeted organizations were previously compromised by other Dukes malware such as CozyDuke, OnionDuke or MiniDuke.
  • on some machines compromised with PolyglotDuke and MiniDuke, we noticed that CozyDuke was installed only a few months before.

However, an attribution based only on the presence of known Dukes tools on the same machines should be taken with a grain of salt. We also found two other APT threat actors – Turla and Sednit – on some of the same computers.

On the other hand, we found strong code similarities between already documented samples and samples from Operation Ghost. We cannot discount the possibility of a false flag operation, however, this campaign started while only a small portion of the Dukes’ arsenal was known. In 2013, at the first known compilation date of PolyglotDuke, only MiniDuke had been documented and threat analysts were not yet aware of the importance of this threat actor. Thus, we believe Operation Ghost was run simultaneously with the other campaigns and has flown under the radar until now.

PolyglotDuke (SHA-1: D09C4E7B641F8CB7CC86190FD9A778C6955FEA28) uses a custom encryption algorithm to decrypt the strings used by the malware. We found functionally equivalent code in an OnionDuke sample (SHA-1: A75995F94854DEA8799650A2F4A97980B71199D2) that was documented by F-Secure in 2014. It is interesting to note that the value used to seed the srand function is the compilation timestamp of the executable. For instance, 0x5289f207 corresponds to Mon 18 Nov 2013 10:55:03 UTC.

The IDA screenshots in Figure 3 show the two similar functions.

Figure 3. Comparison of a custom string encryption function found in PolyglotDuke (on the left) and in OnionDuke (on the right) samples from 2013

Further, recent samples of the MiniDuke backdoor bear similarities with samples documented more than five years ago. Figure 4 is the comparison of a function in a MiniDuke backdoor listed by Kaspersky in 2014 (SHA-1: 86EC70C27E5346700714DBAE2F10E168A08210E4) and a MiniDuke backdoor (SHA-1: B05CABA461000C6EBD8B237F318577E9BCCD6047) compiled in August 2018.

Figure 4. Comparison of the same function in MiniDuke from 2014 (on the top) and in MiniDuke from 2018 (on the bottom)

Given the numerous similarities between other known Dukes campaigns and Operation Ghost, especially the strong code similarities, and the overlap in time with previous campaigns, we assess with high confidence that this operation is run by the Dukes.

In Operation Ghost, the Dukes have used a limited number of tools, but they have relied on numerous interesting tactics to avoid detection.

First, they are very persistent. They steal credentials and use them systematically to move laterally on the network. We have seen them using administrative credentials to compromise or re-compromise machines on the same local network. Thus, when responding to a Dukes compromise, it is important to make sure to remove every implant in a short period of time. Otherwise, the attackers will use any remaining implant to compromise the cleaned systems again.

Second, they have a sophisticated malware platform divided into four stages:

  • PolyglotDuke, which uses Twitter or other websites such as Reddit and Imgur to get its C&C URL. It also relies on steganography in images for its C&C communication.
  • RegDuke, a recovery first stage, which uses Dropbox as its C&C server. The main payload is encrypted on disk and the encryption key is stored in the Windows registry. It also relies on steganography as above.
  • MiniDuke backdoor, the second stage. This simple backdoor is written in assembly. It is very similar to older MiniDuke backdoors.
  • FatDuke, the third stage. This sophisticated backdoor implements a lot of functionalities and has a very flexible configuration. Its code is also well obfuscated using many opaque predicates. They re-compile it and modify the obfuscation frequently to bypass security product detections.

Figure 5 is a summary of the malware platform of Operation Ghost.

Figure 5. Summary of Operation Ghost malware platform

Third, we also noticed that the operators avoid using the same C&C network infrastructure between different victim organizations. This kind of compartmentalization is generally only seen by the most meticulous attackers. It prevents the entire operation from being burned when a single victim discovers the infection and shares the related network IoCs with the security community.

Our new research shows that even if an espionage group disappears from public reports for many years, it may not have stopped spying. The Dukes were able to fly under the radar for many years while compromising high‑value targets, as before.

A comprehensive list of Indicators of Compromise (IoCs) and samples can be found in the full white paper and on GitHub.

For a detailed analysis of the backdoor, refer to our white paper. For any inquiries, or to make sample submissions related to the subject, contact us at [email protected]

17 Oct 2019 – 11:30AM

Streaming devices track viewing habits, study finds

Do you know what kind of data your streaming device may be collecting while you binge watch?

Steadily, we are adopting more and more technology into our households. Our homes are becoming more interconnected, with IoT (Internet of Things) devices becoming regular parts of our lives. One of the devices that is the centerpiece of most households is the television set – and with it often come internet-connected streaming services. So, what is the trade-in for having the convenience of a vast library of content at your fingertips?

To a certain extent, the trade-in may be your privacy. A study conducted by researchers from Princeton University and the University of Chicago unveils that at least some streaming devices are tracking some of your viewing habits.

The research focused on two streaming devices, Roku and Amazon Fire TV, simply because together they have the largest global market share. The devices are OTT (Over-The-Top), which means they add smart features to your TV, mainly online streaming libraries.

The research found that tracking is prevalent on both platforms, with trackers present on 69% of Roku channels while Amazon Fire TV has trackers on 89% of its channels. On Roku,, a tracking domain owned by Google, is the most dominant tracker, appearing in 975 of the 1,000 tested channels.

In the case of Amazon Fire TV, the dominant tracker is Amazon’s tracking domain appearing in 687 of the 1,000 tested channels. Another two domains connected with Google appear in the top ten trackers present in both tested devices.

Two unique IDs – the AD ID and the serial number – are the most “leaked” unique identifiers. Other unique identifiers that the devices transmit are the device IDs, MAC addresses, Wi-Fi SSIDs and in four instances the email address used to create the account.

The researchers also selected one hundred channels at random to find out whether the devices tracked the viewing tastes of their users. They found out that nine channels on Roku and fourteen on Amazon Fire TV leaked the title of the video to a tracking domain.

The researchers conclude that the privacy countermeasures provided are ineffective when it comes to preventing tracking. They recommend that OTT platforms should provide better privacy features such as those offered by modern browsers, including private browsing. You can read their full set of recommendations and findings in the study.

15 Oct 2019 – 05:35PM

Connecting the dots: Exposing the arsenal and methods of the Winnti Group

New ESET white paper released describing updates to the malware arsenal and campaigns of this group known for its supply-chain attacks

Today, ESET Research releases a white paper updating our understanding of the Winnti Group. Last March, ESET researchers warned about a new supply-chain attack targeting video game developers in Asia. Following that publication, we continued those investigations in two directions. We were interested in finding any subsequent malware stages delivered by that attack, and we also tried to find how the targeted developers and publishers were compromised to deliver the Winnti Group’s malware in their applications.

While we continued that investigation of the Winnti Group, additional reports on their activities were published. Kaspersky released details about the ShadowHammer malware that was found in the Asus Live Update utility. That report also mentioned some of the techniques we describe in detail in this new white paper, such as the existence of a VMProtect packer and a brief description of the PortReuse backdoor. FireEye also published a paper about a group it calls APT41. Our research confirms some of their findings regarding the subsequent stages in some of the supply-chain attacks, such as the use of compromised hosts for mining cryptocurrencies.

Our white paper provides a technical analysis of the recent malware used by the Winnti Group. This analysis further refines our understanding of their techniques and allows us to infer relationships between the different supply-chain incidents.

We hope the white paper and indicators of compromise we release today will help targeted organizations find if they are victims or prevent future compromise.

There are lots of reports about this group’s — or perhaps these groups’ — activities. It seems each report gives new names to the group and the malware. Sometimes, this has been because the link with existing research wasn’t strong enough to classify the malware and activities of interest under a previous name, or, because vendors or research groups have their own classifications and naming and used them in their public reporting. For someone who doesn’t actually analyze the malware samples, it can be difficult to confirm aliases and easy to add more confusion.

We have chosen to keep the name “Winnti Group” since it’s the name first used to identify it, in 2013, by Kaspersky. We do understand Winnti is also a malware family: that is why we always write Winnti Group when we refer to the malefactors behind the attacks. Since 2013, it was demonstrated that Winnti is only one of the many malware families used by the Winnti Group.

To be clear, we do not exclude the idea that there might be multiple groups using the Winnti malware. For the scope of our research we refer to them as potential subgroups of the Winnti Group because there is no evidence they are completely isolated. Our definition of the Winnti Group is broad enough to include all these subgroups because it is based mainly on the malware and techniques they use.

Our white paper has a section describing the names we use and their aliases.

Figure 1. Overview of artefacts, techniques, events and their relationships used by the Winnti Group

We were intrigued by the unique packer used in the recent supply-chain attacks against the gaming industry in Asia. We described its structure in our previous article, and after publication, we continued the hunt to find if it was used elsewhere. The answer was positive. This packer is used in a backdoor the malefactors call PortReuse. After further investigation, we found additional samples of this backdoor with additional context confirming it is actually used in targeted organizations.

This led us on the path to find how it is deployed on compromised hosts. We’ve discovered a VMProtected packer that decrypts position-independent code using RC5, with a key based on a static string and the volume serial number of the victim’s hard drive, and runs it directly. This is exactly the same algorithm used by the second stage malware of the games compromised by the Winnti Group in 2018. There are also other ways the PortReuse backdoor is concealed, but this VMProtected packer using the same cipher and key generation technique strengthens the links between the incidents.

We’ve seen another payload delivered with the same VMProtected packer: the ShadowPad malware. ShadowPad was first seen during the NetSarang supply-chain incident, where their software was bundled with this malware. Nowadays, we see variants of ShadowPad, without the domain generation algorithm (DGA) module, in organizations targeted by the group.

A few weeks after our March article was published, we were able to acquire the third and final stage of the supply-chain attack we described. Once decrypted, the payload was a custom version of XMRig, a popular open source cryptocurrency miner. This was not quite what we expected because the Winnti Group is known for its espionage operations, not for running operations that result in financial gain. Perhaps this virtual money is how they finance their infrastructure (C&C servers, domain names, etc.), but this is just guesswork.

Figure 2. PortReuse backdoor architecture

The PortReuse backdoor does not use a C&C server; it waits for an incoming connection that sends a “magic” packet. To do so, it doesn’t open an additional TCP port; it injects into an existing process to “reuse” a port that is already open. To be able to parse incoming data to search for the magic packet, two techniques are used: hooking of the receiving function (WSARecv or even the lower level NtDeviceIoControlFile) or registering a handler for a specific URL resource on an IIS server using HttpAddUrl with a URLPrefix.

There are variants out there targeting different services and ports. They include DNS (53), HTTP (80), HTTPS (443), RDP (3389) and WinRM (5985).

Thanks to Censys, ESET researchers were able to warn a major Asian mobile software and hardware manufacturer that they were compromised with the PortReuse backdoor. We worked with Censys to perform an Internet-wide scan for the PortReuse variant that injects into IIS.

More details about PortReuse‘s inner workings are described in our white paper.

In addition to the new PortReuse backdoor, the Winnti Group actively updates and uses its flagship backdoor, ShadowPad. One of the changes is the randomization of module identifiers. Timestamps found in each module of the samples indicate they were compiled in 2019.

ShadowPad retrieves the IP address and the protocol of the C&C server to use by parsing content from the Web set up by the attackers, and hosted on popular, publicly available resources such as GitHub repositories, Steam profiles, Microsoft TechNet profiles or Google Docs documents. It also has a campaign identifier in its configuration. Both techniques are also used by the Winnti malware family.

ESET researchers are always on the lookout for new supply-chain attacks. It is not an easy task: identifying small, well hidden, code added to a sometimes-huge, existing code base is like finding a needle in a haystack. We can, however, rely on behaviors and code similarity to help us spot the needle.

We were quite surprised by the final stage we found in the recent supply-chain incident in games. This group is known for its espionage capability, not for mining cryptocurrencies using their botnet. Perhaps they use the virtual money they mine to finance their other operations. Maybe they use it for renting servers and registering domain names. But at this point, we cannot exclude that they, or one of their subgroups, could be motivated by financial gain.

ESET researchers will continue to track this group and provide additional details as the team finds them. If you think you are a victim of this group or have further questions, feel free to reach out our team (via [email protected]) for additional details.

Indicators of compromise are available in our white paper, as well as on in our malware-ioc repository on GitHub.

and 14 Oct 2019 – 11:30AM

Week in security with Tony Anscombe

This week, ESET researchers published an analysis of a previously unknown cyber-espionage platform and described a system enabling them to explore the UEFI landscape in an efficient way

ESET researchers publish an in-depth analysis of Attor, a new cyber-espionage platform used in targeted attacks against diplomats, government officials and privacy-concerned users. Also this week, ESET experts described how they had trained a machine-learning model to recognize a handful of unwanted UEFI components within millions of harmless samples. In advance of AVAR conference, we published an interview with internet pioneer Dr. Paul Vixie to discuss his views on a free and secure internet. All this – and more – on WeLiveSecurity.