- STAR Labs analysed Novinarya, an Android stealer that targets 81 financial apps and reads SMS passcodes. It finds its server through a seller's profile bio on a legitimate marketplace.
- Because the server address is not in the app's code or files, scanning for it finds nothing. Blocking the marketplace is not an option either.
- Track the mechanism, the sample hashes and the app and file names rather than the abused marketplace host. Ask your fraud team how they detect this behaviour.
The address is not in the malware
Security teams often hunt for the server a piece of malware reports to. Novinarya makes that hard. STAR Labs, a security research firm, found no server address anywhere in the app's code, assets, resources or native library.
The pointer to the server was in the app all along. It sat in the manifest, the app's settings file, in encrypted form.
The researcher's advice is that an empty search for a hardcoded server should be read as a sign the search failed, not as a clean result. C2 means the command server the malware talks to. This shows how the cost of a clean scan is shifting. An empty result tells a team the address is stored somewhere else. It does not say the app is safe.
What the stealer does to a customer
STAR Labs describes Novinarya as an Iranian Android banking and crypto stealer. It checks which apps are installed on a phone and matches them against a hardcoded list. The list holds 54 crypto exchanges and wallets and 27 Iranian banking apps.
It does not use the usual overlay or accessibility tricks. The app requests neither permission. Instead it opens a WebView, an in-app browser window, that loads a page controlled by the operator. A script on that page copies what the victim types into the form.
The app also edits the user-agent text it sends, dropping the marker that would reveal an in-app browser. To the operator's page, the visitor looks like an ordinary browser. A broadcast receiver reads incoming SMS and notifications. An encrypted set of rules for 25 banks pulls out account numbers, balances and one-time passcodes.
For a bank or exchange, the customer who types a password into a convincing page is only half the loss. The passcode that should have protected them arrives by SMS and is read by the same app.
How the hidden address works
The chain has three steps, each encrypted.
First, the app's manifest holds an encrypted entry called X_ROUTES. At runtime the app decrypts it using another manifest value, X_CID, as the key. The result is a web address on Basalam, which STAR Labs describes as Iran's large social-commerce marketplace with millions of sellers.
Second, the app fetches that address, which is a seller's profile. It reads the bio field. The bio looks like random text because it is a base64 blob, an encoded string, not a sentence.
Third, the app decrypts the bio. The first ten characters act as the key for the rest. The output is the live command server, which STAR Labs recovered as hxxp://theapi.the-x-services[.]xyz/. Stolen credentials and passcodes are encrypted and sent to that same address.
The operator can move servers by editing one bio field. No new app release is needed. This is a dead drop, in the spy-fiction sense: a public place where a message waits for the right person to pick it up.
Why a blocklist does not solve it
The dead drop sits on a legitimate marketplace. STAR Labs states that Basalam must not be blocked and does not list basalam.com or github.com as an indicator. Blocking a trusted site would hurt real users and miss the point. The abused account is the problem, not the site.
The packaging changes too. STAR Labs compared five related samples. The inner stealer is byte-identical in all of them, with the same SHA-256 hash. What varies from build to build is the outer wrapper and which profile serves as the drop.
Four of the five pointed to one dead-drop account, dxoeG7, which is now banned. The fifth rotated to m6AJm5. That account was live when the researcher tested it, so the real server could be recovered. The researcher notes that this build is the only one that yielded a usable server.
A caveat: STAR Labs does not report how many phones are infected. This is one family, analysed in one report.
What leaders should ask
The lesson here is that reachability is where the operator invests effort, and where defenders' static tools fall short. The harvesting is ordinary. The skill is in keeping the server out of every place a scanner looks. Defence has to follow the mechanism, not only a list of addresses.
Put these questions to your security and fraud teams:
Do we track malware by its behaviour, such as what builds the outgoing request, or only by a list of addresses? The researcher argues that the class which assembles the request URL tells defenders more than a search through the app's strings.
What do our indicators contain? STAR Labs points to sample hashes, package and file names, manifest keys and crypto parameters. It also lists the dead-drop technique and the decrypted command-server domain for this build. Shared marketplaces and code hosts do not belong on that list.
If we run a banking or exchange app, can we detect a customer's session coming from an in-app browser that hides its identity? Do we rely on SMS passcodes for high-value actions?
The malware's address book was a stranger's profile page. A defence built only on lists of bad places will miss it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: STAR Labs.
