Nozomi throws light on malware samples in IoT devices that evade detection and analysis, as adoption grows
Industrial cybersecurity vendor Nozomi Networks found that the number of malware samples found in Internet of Things (IoT) devices increased over the past few years, making these devices become easy targets for hackers. The fact that the IoT default credentials are not being changed and the IoT devices are not being properly configured and/or are not updated, as often as they should, has led to the hardware equipment being targeted by adversaries.
“Attackers either take control of them so they can spy on users or launch an attack against another network or system,” researchers from Nozomi Networks Labs, wrote in a Tuesday blog post. “Additionally, malware authors are using open-source tools to modify their malware so that it evades detection by antivirus software.”
The San Francisco-based firm has previously released data on some widely used modification techniques done to malware samples after being packed with Ultimate Packer for Executables (UPX) to make decompression more difficult.
Nozomi said that it collected 728 malware samples from its IoT honeypots over the course of 15 days, the post said. “696 (95%) of the total are ELF files, ARM being the most targeted architecture (539 samples), followed by MIPS (40 samples) and 386 (35 samples) with less than a tenth of samples. The other files that are not ELF files are mainly bash and python scripts used in different stages of the infection of the machine,” the post added.
Additionally, 317 samples were packed with UPX and only one of them returned an error when Nozomi tested them with UPX. “Additionally, the sample could be easily fixed with the upx-recovery-tool. When we checked which samples implemented the e_sh* UPX headers tampered with 0xffff values, we found eight of them were protected by this method,” the post disclosed.
The researchers then analyzed the malware samples and discovered new modification techniques malware authors are using to evade detection. They are also adopting new methods for crafting malicious files, exploiting a variety of vulnerabilities in IoT devices, and using command-and-control (C&C) servers to maintain control of compromised devices, it added.
In August, Nozomi detailed a UPX recovery tool created to automate the decompression process to make it easier for security researchers. The researchers said that while using the tool consistently over the past few months, they discovered additional evasion techniques malware authors use in their samples. “The idea behind these small modifications is to keep the file executable while making it impossible to completely or even partially parse,” they added.
Nozomi analyzed some protection techniques implemented in standard botnet samples that share code with several malware families, namely with Kaiten/Tsunami. “This malware family behavior and functionality was captured in technical analysis blogs conducted by MalwareMustDie and Stratosphere Lab. The first few protection methods discussed in the blog by MalwareMustDie was about a sample where the UPX!signatures had been overwritten by 0A 00 00 00 and the entry point was modified to start with a call instruction that pointed to the original entry point code,” the researchers disclosed.
Later, according to the Stratosphere Lab, the malware authors included additional countermeasures, like adding junk bytes at the end of the file (in the overlay), the post identified. “Even if an analyst can find and fix the original offsets of all the UPX!signatures, the standard UPX tool still won’t be able to find the PackHeader structure because it expects it at the end of the file.”
“After our analysis, we noticed that the samples from this family have some new modifications that make them more difficult to automatically parse and analyze,” Nozomi said. “The only new UPX-related protection we have seen (compared to the protections reported in other blogs) has been found in a couple of samples where, in addition to the overlay, the authors overwrote the PackHeader structure.”
During its investigation, the researchers found that after fuzzing the ELF header, the three fields (e_shoff, e_shnum, e_shstrndx) could be freely modified, inducing errors in several analysis tools and keeping the sample executable. “This researcher also shared a C code that modifies the ELF executables in the same way we see in the samples in our sandboxes. We think these malware creators are using this same tool. Both the malware authors and the researcher’s tool overwrite only 2 bytes of the e_shoff field, whose size is 4,” the post added.
“For example, the Interactive Disassembler (IDA) tool showed a couple of warnings but was still able to open and analyze them. Hiew, another popular tool, was not able to open this file at all and immediately terminated it,” Nozomi researchers said.
“Even our UPX recovery tool had issues handling these samples as it crashed when it was parsing the ELF headers,” the researchers said. “In this case, pyelftools was the link inside the chain of analysis made to the sample. These unusual values only appear in a very small percentage of the ELF files that exist and that’s why this library was not ready to open these malware files. As this project is open source, this allowed us to submit a couple of improvements to make the library more resilient to these kinds of unexpected values,” they added.
Nozomi said that to properly analyze all aspects of malicious behavior, it makes sense to debug the samples of interest rather than perform static analysis only. “In this particular case, all of them were created to run on Linux environments common for IoT devices (mainly ARM and MIPS architectures) rather than for x86 (32- or 64-bit) which is common for analysts’ host machines. To be able to debug them without a need to set up ARM or MIPS hardware, it is common to use emulators,” the researchers added.
Rather than the full-system emulation mode, Nozomi decided to use QEMU user-mode emulation. “This tool has a very simple setup where you can directly install it from some Linux distributions’ repositories and execute IoT samples on x86 hardware straight away.”
However, this simplicity has a major downside, the researchers pointed out. “If you decide to debug the sample remotely via the GDB protocol, the first thing that may seem unusual is that the sample will need to have execution permissions for the local file system. When restarting the sample a few times, you may also realize that the behavior of the sample can change,” they added.
This is the main difference between virtualization software emulating the whole OS and this QEMU user-mode setup. The emulated sample had full access to the local x86-64-based host machine where it was emulated, was able to change local files, and add a new crontab task, the post said.
Nozomi researchers said that the constant analysis of samples helps them track their evolution and understand how malware developers protect their creations from analysis tools, improving these protections over time. “In order to protect yourself from these attacks, we recommend implementing strong passwords on devices that are accessible from outside networks, setting up firewalls between your network and external connections, installing antivirus software on all devices, and monitoring any changes in device behavior or performance,” they added.
Last week, Nozomi identified thirteen vulnerabilities affecting baseboard management controllers (BMCs) of Lanner devices based on the American Megatrends (AMI) MegaRAC SP-X, five of which are rated as critical. By abusing these vulnerabilities, an unauthenticated attacker may achieve remote code execution (RCE) with root privileges on the BMC, compromising it and gaining control of the managed host.
A complimentary guide to the who`s who in industrial cybersecurity tech & solutions
Free DownloadRelated
