Some time ago, our Research team at Promon wanted to answer a pretty simple question. How many apps out in the wild actually ship our protection? We had numbers from several places but they didn't agree with each other. So, we decided to just scan a lot of apps and write down what we found. This was meant to be a small side project.
It turned into a registry of protected apps that we now look at from several different angles. The registry itself does nothing clever. It downloads apps, checks whether they carry one of our products, and stores what it sees. It runs every night, so over time we accumulate history instead of a single snapshot. The history is the actual value here, because it lets us see what happened to a specific app over time; for example, when it was updated and when it stopped being protected.
The main purpose of the registry today is to improve the security of our customers' apps. We can see whether a customer uses a weak configuration or outdated versions of our products but we can also use it to find repackaged versions of apps we protect. This post is about the repackaging angle. It is how we found Hirudo earlier this year, independently of ThreatFabric, who reported on it in October. Here’s how we found it, who we notified, and what it meant for our products.
Repackaging means somebody takes a real app, modifies it and ships the modified version to users. For app developers, tampering is a serious problem no matter which industry they are in. In finance, the point is usually to remove detection so that ordinary banking malware works again, as we saw in our Coretax RAT investigation. In gaming, it is cheats and private servers; in delivery, order grabbing and GPS spoofing; in retail, coupon farming and checkout bots. One of the core features of Promon Shield is detecting when an app has been tampered with and refusing to let it run.
Previously, we mostly learned about repackaged copies reactively. A customer noticed something, told us and we investigated, often weeks after the attack had started. By then, real people had already lost money. These investigations are also valuable for research and we have found genuinely new attack techniques that way, FjordPhantom and Snowblind being good examples. But we would obviously rather be more proactive.
Read more: Promon discovers new Android banking malware, “FjordPhantom”
The signal we use for that is pretty simple. A repackaged app usually keeps the package name, because otherwise it stops being a drop-in replacement for the real app. And it can't keep the signature, because the attacker doesn't have the publisher's signing key. So a repackaged app is an app with a known package name signed by somebody unexpected. We know the package name of every app we protect and we know who is supposed to sign it, so that comparison is cheap for us to make.
We run this against Koodous, which is basically VirusTotal for Android apps. Researchers and security companies upload the APKs they come across. Koodous analyzes them and everything ends up in a large searchable database of samples. It works well for our purpose. YARA rules run on every new upload and notify us the moment a matching sample arrives, so we see a repackaged copy on the day it appears. Search lets us go back in time and work through samples that were uploaded long before we started looking. Together, that gives us both live monitoring and history.
Read more: App Threat Report: The state of repackaging
For the very first sweep, we picked a short list of apps that we already knew had been repackaged before. One of them had been reported to us by a partner in March 2025. We had analyzed that attack in detail back then. The registry immediately turned up several more builds of the same malware that we had never seen, spread across app versions released over more than a year.
That family is public by now. Group-IB described it as SkyHook in December 2025 and attributed it to a group they call GoldFactory. It embeds a Frida agent into the app and runs an obfuscated attack script inside it to bypass security measures.
The same sweep also returned something that didn't match the first family at all. This is one of the patched banking apps used by the actors behind the campaign that distributes the malware ThreatFabric has named Hirudo. In that sample, the attacker had added a separate DEX file and a native library to the app as assets, plus a copy of the original unmodified app as a third asset. A call to a loader is prepended to the app's own startup code and the loader copies the payloads out of the assets and loads them. Interestingly, nothing happens at all unless a specific file exists on the SD card. This is probably an anti-analysis trick, but it also hints at a second component (the Hirudo RAT) that creates that file.
What the payload then does is fairly standard for a vishing attack. It hides malicious accessibility services from the app, removes FLAG_SECURE so the screen can be recorded, makes the call state always read as idle and makes adb and developer options look disabled. This allows a secondary component to attack the app without protections being in the way.
The sample also carried bypasses for repackaging detection. To our surprise, the app it attacked was no longer protected by us, so those bypasses were aimed at something else.
One thing stood out to us. The sample carried a large hardcoded XML blob with private keys and certificate chains in it. It turned out to be a leaked keybox. What is a keybox and why would something like this be found in a repackaged app?
Turns out it is connected to Android key attestation. Android key attestation lets an app ask the device's secure hardware to generate a key. The operating system tells the secure hardware which app is asking and the secure hardware issues a certificate for the new key, stating which app asked for it and what state the device is in. That certificate is signed with the device's attestation key, whose own certificate is signed by an intermediate one. The chain of certificates ends in a root certificate that Google publishes. So anybody can follow those signatures upwards and convince themselves that the statement really came from genuine hardware. A keybox holds the private keys and the chain that a device is provisioned with in the factory.
We checked the one in the sample. Both private keys found in the keybox matched their leaf certificates, both chains validated against Google's published attestation root and neither key was on Google's revocation list. So this was a genuine keybox and it was still working.
The malware used it to forge an attestation for the repackaged app. An integrity check that trusts key attestation would therefore see a genuine, untampered app.
Whoever has a keybox like this can produce attestations for any key, any app and any device state. All of them validate against Google's root. That is enough to bypass pretty much anything that relies on key attestation. A rooted phone or an unlocked bootloader can be made to look clean, an emulator can attest as real hardware, and a key can be made to look like it came from an app with a specific signer.
This is actually more serious than we initially realized. The damage isn't limited to the app we found it in. Every app, every bank, and every enterprise that relies on key attestation was affected by this one file, without any of them having been attacked or even knowing about it.
The first sample made it look like this wasn't a one-off attack. The bypasses were written against several different products and not just against the one in the app we were looking at. On top of that, there were strings and build paths left in the binaries that referenced a second bank, which wasn't the one being attacked here. All of this looks much more like a toolkit that somebody maintains than like a single app being targeted once.
That raised the question we actually cared about. Does this toolkit also attack apps that we protect? Every package we protect is in our registry, so we could answer that as soon as we had the full set of samples. The problem was getting them.
Koodous didn't turn up anything else. So, we shared what we had with experts in the region targeted by the malware. They had been investigating the same actor and provided us with additional indicators of compromise. With those, we could hunt on VirusTotal, which is where the rest of the family showed up. In the end, we could account for nine samples covering eight different banking apps.
The good news for us and our customers was that none of the apps in that set were protected by us when they were attacked. That is, of course, a good outcome, but it only says that we and our customers weren't targeted. It doesn't tell us whether the attack would have worked against our products.
This was the most important question we had to answer for ourselves and for our customers. We didn't want to just assume the answer, so we started by reproducing the attack. We ran the same attack against test apps protected by our products. The good news is that the attacks didn't work on Promon protected applications. The test apps were detected as repackaged, because the bypasses in the sample were written for different kinds of integrity checks than the ones Promon Shield uses. Nothing in the toolkit appears to have been built with our products in mind and none of it carried over.
In August, we contacted Google about the leaked keybox. It has been revoked since then. We also notified the vendor whose product was bypassed in the samples we analyzed.
Since the malware wasn't attacking our products but someone else's, we didn't think it was our place to tell the public about it. But now that ThreatFabric has reported on it, we thought it was time to tell our story as well.
Read more: AI-assisted vulnerability research still requires responsible disclosure
The registry started as a side project to answer a counting question. How many apps out there actually ship our protection? We have that number now, but the registry itself has turned into something much more useful. Today, we use it to find security issues in our own products and in the apps we protect. The repackaging scans show us a modified copy on the day it is uploaded instead of weeks later when somebody complains, which is what lets us see attempted bypasses of our protections before they can do much damage.
The first real result of all this wasn't about us at all. The malware we found was attacking apps that we don't protect and the most serious thing in it was not our problem either. A leaked keybox is a problem for everybody who relies on Android key attestation. We reported it to Google and the keys have been revoked by now. We also notified the vendor whose protection the toolkit was written to bypass, so they could look at it on their side. Neither of these changes the world, but together they make this particular toolkit a bit less useful. What came out of our side project is a small improvement for mobile security in general rather than for Promon. We think that is a good enough reason to do this kind of work.
None of our products turned out to be affected by any of this, and we checked that rather than assuming it. This is the part we would like to emphasize. "This doesn't affect us" is a cheap sentence and it is only worth something if somebody actually sat down and tried it.