{ "id": "0315fb24-c89b-47e9-9a5e-4868936349cd", "created_at": "2026-04-10T03:21:33.098575Z", "updated_at": "2026-04-10T03:22:17.955316Z", "deleted_at": null, "sha1_hash": "460d7679609951d72b284f6bc5fd9450436f9732", "title": "Into Android Meterpreter and how the malware launches it — part 2", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 571079, "plain_text": "Into Android Meterpreter and how the malware launches it — part\r\n2\r\nBy @cryptax\r\nPublished: 2020-09-25 · Archived: 2026-04-10 03:08:09 UTC\r\n4 min read\r\nSep 25, 2020\r\nThis is a part 2 of “Locating the Trojan inside an infected COVID-19 contact tracing app”. We are going to\r\nexplain how the malware works.\r\nConnecting to attacker’s server\r\nIn part 1, we explained a genuine COVID-19 contact tracing app was trojanized with a Java-based Meterpreter.\r\nThe sources of what gets injected in the app can be found on GitHub. The most important part is located in\r\nPayload.java (details: the main entry point is MainActivity , which starts a MainService , which instantiates\r\nPayload ). The Payload class does the following:\r\n1. Read the hard coded exploit configuration ( configBytes ). We will detail the contents of the\r\nconfiguration later.\r\nprivate static final byte [] configBytes = new byte[] { (byte) 0xde\r\n2. Ensure the smartphone’s CPU remains on: PARTIAL_WAKE_LOCK keeps the CPU running while allowing the\r\nscreen and keyboard back light to go off (more stealthy).\r\nPowerManager powerManager = (PowerManager) context.getSystemService(Context.POWER_SERVICE);\r\n3. Hide the icon’s application if requested:\r\nif ((config.flags \u0026 Config.FLAG_HIDE_APP_ICON) != 0) { hide\r\n}\r\n4. Open a socket towards the attacker’s server (this is called a reverse shell).\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@cryptax/into-android-meterpreter-and-how-the-malware-launches-it-part-2-ef5aad2ebf12\r\nPage 1 of 5\n\nThe argument “url” is read from the malware’s hard coded configuration. It contains the host and\r\nport to connect to in (else). Or if the host is missing, a server Socket is created on the port\r\nmentioned in the config.\r\nHard-coded configuration\r\nThe malware’s configuration is handled by classes ConfigParser and Config . We won’t detail how it works,\r\nbut if you reverse the code, this is what the configuration contains:\r\nPress enter or click to view image in full size\r\nFormat of hard coded configuration bytes. This can be completed optionally by other parameters\r\nsuch as proxy host, user, password, user agent…\r\nhttps://medium.com/@cryptax/into-android-meterpreter-and-how-the-malware-launches-it-part-2-ef5aad2ebf12\r\nPage 2 of 5\n\nIn this configuration, the important part for us is the “URL” , which explains how to connect to the attacker’s host.\r\nIt can be via TCP or HTTP. Consequently, if we search the DEX executable(s) for tcp:// (or http:// ) we find\r\nthe server:\r\n$ strings classes.dex | grep \"tcp://\"\r\ntcp://87.19.73.8:24079\r\nHow the server sends commands\r\nRemember the video in Part 1: at the other end, once connected, the attacker can issue several commands such as\r\ndump_sms . This is possible because as soon as the connection is established, Metasploit sends a Jar to the\r\nvictim, which implements all commands.\r\nPress enter or click to view image in full size\r\nOn the smartphone, this is the code which gets called once a session is established with the remote\r\nserver. The input stream (in) is a Jar (stageBytes) sent by the attacker. The attacker specifies which\r\nclass name should be loaded (classFile) and the code automatically calls method start() within this\r\nclass.\r\nThe implementation of commands supported by the Jar can be found here. And the list of commands is here.\r\nHow is the malicious code triggered?\r\nUp to now, we know (1) where the malicious code is (see part 1) and (2) how it works (above — explanation on\r\nMeterpreter’s code). But where / when is it launched? The answer to this question is different from one sample to\r\nanother.\r\nhttps://medium.com/@cryptax/into-android-meterpreter-and-how-the-malware-launches-it-part-2-ef5aad2ebf12\r\nPage 3 of 5\n\nIn f3d452befb5e319251919f88a08669939233c9b9717fa168887bfebf43423aca , the malware author(s)\r\nsimply forgot to launch the malicious code! They didn’t even mention the malicious activity and service\r\nin the manifest, so it is not possible to launch the malicious part after installation with a shell command am\r\nstart -n xxx . As this sample is not obfuscated either, we can imagine it was an early test of the malware\r\nauthor(s), and they improved their samples later.\r\nIn 7b8794ce2ff64a669d84f6157109b92f5ad17ac47dd330132a8e5de54d5d1afc , the malicious part is\r\nlaunched in an intelligent way I had never encountered personally. In Part 1, we had mentioned the sample\r\nused multiple DEX files and said we’d elaborate on that later. There it is: there are several ways to start a\r\nmulti-dex app, the malware author(s) chose to use androidx.multidex and override\r\nMultiDexApplication . This is where it is interesting: the malicious part is directly launched from the\r\nMultiDexApplication:\r\nPress enter or click to view image in full size\r\nThe MultiDexApplication constructor starts the malicious service, Xmevv. That’s how everything\r\nbegins.\r\nAs android… and androidx…. namespaces are used in nearly every Android application (and genuine),\r\nreverse engineers won’t probably intuitively search in those classes, so it’s a clever way to be stealthy.\r\nGet @cryptax’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nSample 992f9eab66a2846d5c62f7b551e7888d03cea253fa72e3d0981d94f00d29f58a uses the same technique, but\r\nfor a reason I haven’t investigated, the sample crashes on all emulators I have tried.\r\nWho is behind those malicious samples?\r\nhttps://medium.com/@cryptax/into-android-meterpreter-and-how-the-malware-launches-it-part-2-ef5aad2ebf12\r\nPage 4 of 5\n\nI won’t risk myself into any attribution — it’s near impossible to get things right. But, based on the techniques we\r\nhave seen, we can imagine the following profile:\r\nAll samples were released approximately at the same time and “signed” by the same identity “Raven”. It is\r\nlikely they have been implemented by a single author, and not several authors.\r\nThe malware author clearly knows about Metasploit. This can possibly mean s/he is in the vulnerability/\r\nexploit/ security business. S/he could also be a clever student interested in computer security. But\r\ndefinetely, a random person in the street has never heard about Metasploit and does not know how to use it\r\n(a random person in the street fortunately does not code malware, true 😏 ).\r\nIt could also be a (lame) test / Proof of Concept. I am not convinced that those samples have been actively\r\nused against random victims: the connection to the attacker’s server is so visible, and the same IP\r\naddress is re-used over several samples. Perhaps the samples were used on a targeted victim. Or maybe to\r\nimpress a friend or a colleague. But this is just my personal feeling, I may be completely wrong.\r\nSource: https://medium.com/@cryptax/into-android-meterpreter-and-how-the-malware-launches-it-part-2-ef5aad2ebf12\r\nhttps://medium.com/@cryptax/into-android-meterpreter-and-how-the-malware-launches-it-part-2-ef5aad2ebf12\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://medium.com/@cryptax/into-android-meterpreter-and-how-the-malware-launches-it-part-2-ef5aad2ebf12" ], "report_names": [ "into-android-meterpreter-and-how-the-malware-launches-it-part-2-ef5aad2ebf12" ], "threat_actors": [], "ts_created_at": 1775791293, "ts_updated_at": 1775791337, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/460d7679609951d72b284f6bc5fd9450436f9732.pdf", "text": "https://archive.orkl.eu/460d7679609951d72b284f6bc5fd9450436f9732.txt", "img": "https://archive.orkl.eu/460d7679609951d72b284f6bc5fd9450436f9732.jpg" } }