Into Android Meterpreter and how the malware launches it — part 2

This is a part 2 of “Locating the Trojan inside an infected COVID-19 contact tracing app”. We are going to explain how the malware works.

Connecting to attacker’s server

In part 1, we explained a genuine COVID-19 contact tracing app was trojanized with a Java-based Meterpreter. The sources of what gets injected in the app can be found on GitHub. The most important part is located in Payload.java (details: the main entry point is MainActivity, which starts a MainService, which instantiates Payload). The Payload class does the following:

private static final byte [] configBytes = new byte[] {                                   (byte) 0xde, (byte) 0xad, (byte) 0xba, (byte) 0xad, //placeholder                                   /*8192 bytes */ 0, 0, 0, 0, 0,... };...Config config = ConfigParser.parseConfig(configBytes);
PowerManager powerManager = (PowerManager)  context.getSystemService(Context.POWER_SERVICE);                                   wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, Payload.class.getSimpleName());                                   wakeLock.acquire();
if ((config.flags & Config.FLAG_HIDE_APP_ICON) != 0) {                                           hideAppIcon();         
}
The argument “url” is read from the malware’s hard coded configuration. It contains the host and port to connect to in (else). Or if the host is missing, a server Socket is created on the port mentioned in the config.

Hard-coded configuration

The malware’s configuration is handled by classes ConfigParser and Config. We won’t detail how it works, but if you reverse the code, this is what the configuration contains:

Format of hard coded configuration bytes. This can be completed optionally by other parameters such as proxy host, user, password, user agent…
$ strings classes.dex | grep "tcp://"
tcp://87.19.73.8:24079

How the server sends commands

Remember the video in Part 1: at the other end, once connected, the attacker can issue several commands such as dump_sms. This is possible because as soon as the connection is established, Metasploit sends a Jar to the victim, which implements all commands.

On the smartphone, this is the code which gets called once a session is established with the remote server. The input stream (in) is a Jar (stageBytes) sent by the attacker. The attacker specifies which class name should be loaded (classFile) and the code automatically calls method start() within this class.

How is the malicious code triggered?

Up to now, we know (1) where the malicious code is (see part 1) and (2) how it works (above — explanation on Meterpreter’s code). But where / when is it launched? The answer to this question is different from one sample to another.

  • In 7b8794ce2ff64a669d84f6157109b92f5ad17ac47dd330132a8e5de54d5d1afc, the malicious part is launched in an intelligent way I had never encountered personally. In Part 1, we had mentioned the sample used multiple DEX files and said we’d elaborate on that later. There it is: there are several ways to start a multi-dex app, the malware author(s) chose to use androidx.multidex and override MultiDexApplication. This is where it is interesting: the malicious part is directly launched from the MultiDexApplication:
The MultiDexApplication constructor starts the malicious service, Xmevv. That’s how everything begins.

Who is behind those malicious samples?

I won’t risk myself into any attribution — it’s near impossible to get things right. But, based on the techniques we have seen, we can imagine the following profile:

  • The malware author clearly knows about Metasploit. This can possibly mean s/he is in the vulnerability/ exploit/ security business. S/he could also be a clever student interested in computer security. But definetely, a random person in the street has never heard about Metasploit and does not know how to use it (a random person in the street fortunately does not code malware, true 😏 ).
  • It could also be a (lame) test / Proof of Concept. I am not convinced that those samples have been actively used against random victims: the connection to the attacker’s server is so visible, and the same IP address is re-used over several samples. Perhaps the samples were used on a targeted victim. Or maybe to impress a friend or a colleague. But this is just my personal feeling, I may be completely wrong.

Mobile and IoT malware researcher. The postings on this account are solely my own opinion and do not represent my employer.