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

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 (details: the main entry point is MainActivity, which starts a MainService, which instantiates Payload). The Payload class does the following:

  1. Read the hard coded exploit configuration (configBytes). We will detail the contents of the configuration later.
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://"

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 f3d452befb5e319251919f88a08669939233c9b9717fa168887bfebf43423aca , the malware author(s) simply forgot to launch the malicious code! They didn’t even mention the malicious activity and service in the manifest, so it is not possible to launch the malicious part after installation with a shell command am start -n xxx. As this sample is not obfuscated either, we can imagine it was an early test of the malware author(s), and they improved their samples later.
  • 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:

  • All samples were released approximately at the same time and “signed” by the same identity “Raven”. It is likely they have been implemented by a single author, and not several authors.
  • 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.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


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