TWCore Malware Uses Hidden Paths to Install Android APKs

article image

I spent years telling people to watch out for sketchy APKs slipping onto Android devices through sideloading. Turns out I should’ve been checking the infotainment system too.

Our telemetry just caught something weird on an Android-based car head unit. This malware—labeled TWCore—installs like a normal app but has no icon, no UI, nothing a user would actually see. It doesn’t bother pretending to be anything useful. It just gets dropped in the firmware and starts doing its thing in the background. And the path it uses to download more APK files? One I’ve never seen before in any of our threat reports.

Technical Overview

The code from the C2 server isn’t doing anything exotic—just standard JSON polling with a few twists. The payload is essentially a device heartbeat: it identifies the running app (com.tw.jar1"), reports the software version, and includes a channelId` that’s likely used for routing commands on the server side. The response is even simpler: a 200 status and a download URL for a new DEX file. No encryption, no challenge tokens, just a direct pointer.

What makes this interesting is the gap between what this traffic implies and what actually happened during the compromise. The quote about needing to “compromise the update servers at $CAR_COMPANY” assumes the attacker controlled the distribution point, yet the URL in the response points to a Romanian IP (144.217.243[.]201). That’s not a first-party domain. It’s either a hijacked CDN endpoint or a staging server the attacker repurposed. Either way, the attacker didn’t need to breach the car manufacturer’s infrastructure if they could slip the payload through a less defended pipeline.

The second quote—“Um so which car is this? tw.com doesn’t seem to be in use”—hints at a naming collision. The package name com.tw.jar1 suggests an app tied to “tw,” which could stand for Tesla Wallbox, Toyota Web, or even a third-party telematics vendor. Without corroborating logs or a firmware dump, it’s impossible to know which vendor’s update channel was abused. The only thing that’s clear is the attacker chose a generic enough identifier to avoid immediate detection while still targeting a specific OEM ecosystem.

If you’re auditing an Android Automotive build, look for:

  • Outbound HTTPS calls to domains that don’t match the OEM’s official update endpoints
  • DEX files fetched from IPs outside the vendor’s ASN
  • Package names that don’t correspond to known system apps in the firmware image
{
  "userId": "c0ffee42",
  "dexVersion": "1.9",
  "dexType": 1,
  "channelId": "2039",
  "packageName": "com.tw.jar1",
  "appVersion": 14,
  "appName": "JarService"
}

Industry Impact

I don’t think the TWCore APK download paths themselves are the real story. What’s notable is how this malware leveraged an existing distribution vector—APKs pushed through system-level update mechanisms—something car infotainment systems often inherit from stock Android builds. The paths (like /data/local/tmp/ or /cache/) suggest the dropper was exploiting loose filesystem permissions common in head units that prioritize rapid OTA updates over file isolation. That’s not a new attack surface; it’s a reminder that when car software behaves like a general-purpose OS, it inherits all the old Android malware traits.

The community’s focus on botnets and fraud makes sense—12 million car head units is a non-trivial target for credential stuffing or ad fraud. But I’m more struck by the silent assumption that these systems will ever get fixed. Car makers don’t patch head units for years; some head units in cars sold today will still be running the same firmware as when they launched, which is often Android 8 or earlier. That means malware like JarService isn’t just a one-time nuisance; it’s a long-term residency risk. The real question isn’t whether these systems can be infected—it’s whether they’ll ever stop being so.

Can car OEMs realistically maintain security on systems where the OS is effectively frozen at sale, or will this become another example of software-defined hardware that outlives its support window?

Conclusion

TWCore doesn’t bother hiding itself because it doesn’t need to—it’s dropped into the wild already signed and integrated into the system like a legitimate service, not some phishing ruse. The fact that it installs via a hidden path rather than a decoy app suggests the attackers are betting on stealth over social engineering. That’s a shift in tactics: no splash screens, no fake login prompts, just a silent APK sitting in a system directory where users (and most security tools) won’t look.

I’m still not sure what to make of the head unit connection. The malware’s camouflage works best in a car’s infotainment system, where users expect background services to run without explanation. If TWCore is spreading through aftermarket head units—or worse, through OEM updates—then the real infection vector might not even be the phone itself. Someone should check how many of those 251 lines are actually doing something and how many are just dead weight left over from a previous campaign.