Malware details

Metadata

MITRE ATT&CK^®

This report has been compiled with respect to the MITRE ATT&CK® framework, a globally accessible knowledge base of adversary tactics and techniques based on real-world observations.

Persistence

netd is designed to persist on the system by replacing the legitimate netd system binary at the path /system/bin/netd. This replacement is not carried out by the malware, but it can be extrapolated from the checks that it carries out. This is the only Infamous Chisel component which persists.

When the malicious netd is executed, it will check if init is the parent process which executed it. This parent process is responsible for creating the processes listed in the script init.rc. The malicious replacement netd when executed in this way will fork and execute the legitimate process backed up at the path /system/bin/netd_ passing through the command line parameters. This retains the normal functionality of netd, while allowing the malicious netd to execute as root. This replacement would require an escalated privilege level to perform.

If it doesn’t find itself at the /system/bin/netd path, it will fork and set its parent process ID to 1, also attempting to kill the legitimate netd process.

Note: This information would facilitate lateral movement within the network and illustrates a clear intention to interact with other nearby hosts.

On completion of this scan, the .ndata.tmp file is moved to the filename .ndata.csv in the same directory. This file is exfiltrated immediately, and both files removed from the tmp directory.

The contents of this file will appear similar to:

The following command line parameters are present, but only a small portion is used:

Command line help is also included:

td

The td utility provides Tor directory services and is compiled for ARM with no obvious modifications. The configuration for this is generated by the blob component, used for Tor management, described in the Components (blob) section, and saved at the path /data/local/prx.cfg. This file contains:

This configuration provides a Socket Secure version 4 (SOCKS4) connection on the local port 1129 enabling the Tor network to be used. The blob component uses this for network connectivity checks.

The hidden service port is set to 34371 with the directory for hidden service information being set to /data/local/prx/hs/.

During the execution of td an .onion domain for a hidden service is randomly generated at the path /data/local/prx/hs/hostname which is then exfiltrated by netd. The db component performs further configuration detailed in the Multi-call binaries (Watchdog) section of this report to enable a SSH connection via this .onion domain. This gives the actor the ability to create an SSH session by connecting to the hidden service across Tor.

blob

The blob component is responsible for configuring Tor services and checking network connectivity. Every 15 seconds the tmp directory is checked for the blob utility, and if found, it is moved to the /data/local directory from the /data/local/tmp/blob directory, overwriting any existing version. Every 6,000 seconds (1 hour and 40 minutes) blob is then run from the /data/local directory.

netd executes blob which is responsible for configuring and executing Tor services provided by td. When run, it performs the following actions:

1. Checks local host for the port 1129 being open, exiting if it is.


2. Checks for the existence of /data/local/td. If this is not present, extracts it from /data/local/td.bz2 (bzip2 compressed data).


3. Creates the configuration file at the path: /data/local/prx.cfg. The contents of which are detailed in the Components (td) section above.


4. td is executed with this configuration file being supplied with the -f command line parameter: /data/local/td -f /data/local/prx.cfg.


5. db the modified Dropbear SSH utility is checked for at the path /data/local/db. If this file is not present, it is extracted from /data/local/db.bz2. db is then executed immediately after, with no command line parameters being passed.


6. blob then enters a loop where it performs a network connectivity check against the domain www.geodatatool[.]com connecting on the local SOCKS4 address provided by the td utility 127.0.0[.]1:1129 every 3 minutes.


7. It checks the second byte of the response from this domain to be the character Z (0x5a) to validate a legitimate response has been received from the server. Nothing further is done with the data; this is simply an internet connection check.


8. If this request fails or the server doesn’t return the expected data, blob terminates the execution of td.

tcpdump

The tcpdump utility (version 4.1.1) is compiled for ARM with no obvious modifications. This provides traffic capturing and monitoring functionality via the command line.

Multi-call binaries: db, NDBR_armv7l and NDBR_i686

The db utility contains multiple individual utilities which are selected based on the command line parameters supplied:

The command line help for dropbear, dropbearkey, nmap and scp can be found in the Appendix Section of this report.

dropbear, present within db, provides secure shell access to the device via the Tor hidden service. IP Tables rules configured allow incoming TCP connections destined for port 34371 through the firewall. The Tor utility executed by blob on the device is configured to provide a hidden service on this port, then forward connections to the local dropbear instance. The .onion address has already been exfiltrated enabling the actor to connect to it. Modifications have been made to dropbear authentication mechanisms.

The scp utility does not appear to have been modified. The nmap utility has the same functionality as the version in netd but is executed manually by actor interaction.

The watchdog, rmflag, and mkflag utilities appear to be additional actor-created code that has been incorporated to perform some configuration for dropbear.

The directory sessions.log.d is created under /data/local/tmp/, and puts all standard Dropbear files under this directory alongside the custom actor file remove_file.flag.

Watchdog

The watchdog utility performs setup and executes dropbear. This setup includes:

File and directory creation

• /data/local/tmp/sessions.log.d


• /data/local/tmp/sessions.log.d/.ssh


• /data/local/tmp/sessions.log.d/.ssh/remove_file.flag

The remove_file.flag file is created containing the string run when any of the multi-call utilities run Dropbear. This will be collected and exfiltrated by netd giving the actor an indicator that the SSH server is active.

Authorized hosts setup

A host key is placed into the directory:

/data/local/tmp/sessions.log.d/.ssh/authorized_keys

IP Tables Rules

/usr/sbin/iptables is executed with the parameters:

-A INPUT -p tcp --dport 34371 -j ACCEPT -I

mkflag

The mkflag utility creates the directories and files that watchdog creates but does not perform any host file or IP table manipulation, and then runs dropbear.

rmflag

The rmflag utility deletes /data/local/tmp/sessions.log.d/.ssh/remove_file.flag

Modified Dropbear functions

The actor has modified authentication mechanisms in Dropbear.

fill_passwd

The Dropbear function fill_passwd is used to verify that a supplied username is a valid account and return information required to process authentication.

The unmodified source code for this can be found in the Appendix (Dropbear fill_passwd function) Section of this report.

This function calls multiple Linux library functions, getpwnam, getspnam, getpwuid, but in the modified version actor replacement functions are called instead, each of these are discussed below.

getpwnam

getpwnam Linux library function accepts a username and cross-references it with the passwd file usually stored at /etc/passwd for the corresponding entry containing the colon concatenated fields:

• username


• user password


• user ID


• group ID


• user information


• home directory


• shell program

On most modern systems, an x in the user password field is used to denote that the password hash is stored in the /etc/shadow file that requires root privileges to read. On an Android device, there are typically no such files, so the structure that would usually be retrieved from the passwd file is generated instead.

The actor has replaced this function with their own, where if a particular username is seen it returns a hard-coded response. If the expected username is not seen, the /etc/passwd file is checked for the corresponding username as normal.

getpwuid

getpwuid Linux library accepts a uid and returns the corresponding structure above typically from the /etc/passwd file. The actor has replaced this function to check for the uid of 0xbeef and return the hard-coded structure detailed above, if found. If 0xbeef is not seen, it will revert to checking /etc/passwd.

getspnam

getspnam Linux library function accepts a username and cross-references it with the shadow file usually stored at /etc/shadow for the corresponding entry that contains the dollar concatenated fields:

• id


• salt


• hash

Typically, on an Android device, this function would return NULL, but the actor replacement function uses the Linux version.

There does not appear to be any modifications other than those detailed above, but there may be other patches implemented.

NDBR

The NDBR_armv7l and NDBR_i686 utilities contain multiple individual utilities compiled for ARM and x86 respectively. They both include the above authentication mechanism modification, although with different credentials, and otherwise appear to be the same.

These utilities also have some functionality overlap with the VPNFilter malware but appear to be an evolution.[1]

killer

killer is a simple program, the main purpose of which is to terminate netd.

It achieves this by performing the following steps:

1. Iterates through all Process Identifiers (PIDs) in the range 2 through to 0x3FFFFF.


2. Checks the first line of /proc//status for the string netd.


3. Checks the target of the link referenced at /proc//exe against netd.


4. Checks the executable name is not netd_ (The legitimate backup executed by the malicious netd).


5. Terminates the malicious netd leaving the legitimate netd_ running.

netd file exfiltration

When a file is to be exfiltrated, a Transport Layer Security (TLS) connection is initiated to a hard-coded local IP and port.

If a connection to the local IP and port fails, a hard-coded domain is used as a fallback connection. The IP address for this domain is resolved using a request to dns.google.

The following HTTP Post request is used to exfiltrate data:

The Infamous Chisel components are low to medium sophistication and appear to have been developed with little regard to defense evasion or concealment of malicious activity.

The searching of specific files and directory paths that relate to military applications and exfiltration of this data reinforces the intention to gain access to these networks. Although the components lack basic obfuscation or stealth techniques to disguise activity, the actor may have deemed this not necessary, since many Android devices do not have a host-based detection system.

Two interesting techniques are present in Infamous Chisel:

• the replacement of the legitimate netd executable to maintain persistence.


• the modification of the authentication function in the components that include dropbear.

These techniques require a good level of C++ knowledge to make the alterations and an awareness of Linux authentication and boot mechanisms.

Even with the lack of concealment functions, these components present a serious threat because of the impact of the information they can collect.