Fake imToken download sites push an Android app that sends recovery phrases and private keys to one server: technical analysis

Key findings

1. The download page offers an Android app that is not imToken. NSS downloaded the file on 13 November 2026 and read it without running it. Its package name is com[.]anonymous[.]wallet, not the official im[.]token[.]app, and it is signed with a generic debug certificate. The page shows a SHA-256 beside the download button, as the real page does; the file it links has a different one.
2. The app's code sends the recovery phrase and account list of every wallet created or imported in it to pt888999[.]com. It hands phrase creation, wallet creation, phrase and key import, and every transfer, private key included, to api[.]quick-node[.]com, its main back end, a name that imitates QuickNode, a real blockchain-node provider that is not involved. A browser that opens api[.]quick-node[.]com is sent on to the real provider's website. On 13 November both names resolved to one address, 195.245.242[.]143. Neither name is on any threat list NSS takes in.
3. No page NSS loaded asks for a recovery phrase, a private key or a wallet connection. The pages copy the Chinese imToken website behind a visitor check that only a real browser passes, and ask the visitor to install the app. NSS loaded the imToken copy on 2 of the 53 names on 13 November; its 23 stored capture attempts on 12 November saw only the visitor check. The "Android APK" button links to a cloud storage bucket named imtokemapp (a misspelling); the "Google Play" button goes to a redirect link on another domain, not to Google Play.
4. NSS recorded 53 look-alike names from the daily lists of newly registered names, registered between 7 and 11 November 2026 and resolving to four forwarding addresses. 49 share one shape: a short made-up word, 45 of them starting "tok" (tokenism, tokeniem, tokinbin) and four not (two timerime names, timeaim, tolearn), then "-cdn" and a number, then a place code such as hk or sg and a number, on a cheap ending such as .lol or .xyz. The other four are mtokeni[.]vip, mtokeni[.]biz, tokenmi[.]vip and hellogpt-cdn[.]club.
5. The names were bought at one registrar, most of them in bursts. With 13 more names of the same shape bought on 10 November, which NSS also recorded itself, there are 66: five purchases of ten names, each inside 2 seconds, hold 50 of them. 24 of the 53 were on registry hold by 13 November, so they no longer resolve.
6. Each name points at its own random eight-character label under a forwarding domain, and every label points at one shared host under the same domain. 33 of the 53 used ikunzf[.]online, which has carried names of this shape since at least 25 October; the last 20 used yumsihjkk[.]cc, bought on 11 November at 04:47 UTC; a third, shenswdns[.]cc, was bought ten minutes later. Labels keep their names when a site moves between these domains, so one table of labels sits behind all three.
7. Four addresses carried the 53 when NSS first resolved them: 82.158.231[.]42 (20 names), 103.38.82[.]202 (14), 156.225.24[.]119 (10) and 156.225.24[.]233 (9). NSS classes all four as dedicated: every name seen on them belongs to this forwarding set of look-alikes. NSS cannot rule out other customers of the service.
8. NSS's own record is not complete. At least 2 names from the same purchases reached NSS only from lists: tokininx-cdn18-hk78[.]lol, bought in the same second as tokieninn-cdn18-hk79[.]homes on 8 November, and tokeimxn-cdnnode-sg53[.]lol, bought in the same second as timerime-cdn3-hk62[.]xyz on 9 November. Lists also carried tokanix-cdn87-hk43[.]lol, a name of the same shape on the same forwarding, on 7 November, before NSS recorded any of the 53.

How an analyst finds this with NSS

The same case, worked the way a defender works it in NSS: from one new name to the action. Every picture is the real Station on 13 November 2026, cropped to the panel in use.

1. 01Step 1. A new name such as tokenism-cdn14-hk19[.]lol comes in. Investigate rates it Suspicious and ties it to the other names bought in the same second.

   

2. 02Step 2. Sightline shows what the page served when NSS captured it: a visitor check on a dedicated host, with nothing loaded from anywhere else.

   

3. 03Step 3. The casefile of pt888999[.]com cites the app NSS read: its hash, its package and the job the name does in it.

   

4. 04Step 4. On Scan, a three-step tool chain links the two collector names to one server: address lookup, the names NSS has seen on that address, and their registration records.

   

5. 05Step 5. The family finder widens one name to its whole naming family.

   

6. 06Step 6. Then act: watch the names and the address, share the casefile, or download it as JSON or CSV for your own tools (Full features).

   

Automate it with the NSS API

Every NSS check is JSON: a risk band, the host class, how many names share the host, the public-listing state and the time of the answer. The public check needs no key and takes one domain name or one IP address, a few checks a day for each network. A Full account adds API keys, each with its own daily allowance and a limit per minute, made on the account's API keys page.

NAME=$(jq -r '.indicators[0].value' nss-tk-01.json)   # the first name in the paper's file
curl -s "https://nsshq.com/api/v1/check?value=$NAME"

{
  "as_of": "2026-11-13T18:37:47Z",
  "band": "High risk",
  "band_is_host_class": false,
  "found": true,
  "host_class": {
    "as_of": "2026-11-13T17:30:47Z",
    "class": "dedicated",
    "label": "Dedicated host",
    "sentence": "Dedicated host (...)."
  },
  "known_good": false,
  "names": {
    "at_least": false,
    "listed": null,
    "total": 3
  },
  "public_listing": { (...) },
  "reports": 0,
  "type": "domain",
  "value": "pt888999[.]com",
  "view": "public"
}

#!/usr/bin/env python3
"""Check every name and address in an NSS paper's indicator file and flag verdict changes (cron or SIEM enrichment).

  python3 nss_check_file.py nss-tk-01.json
Without a key it uses the public check (no key needed, a few checks a day per network). With a Full account, create a key on the API keys
page, then set NSS_API_KEY to the key and NSS_API_URL to the request that page shows. The key is sent only in the Authorization
header, never in the address. Prints one JSON line per indicator; exits 2 when a verdict changed since the last run.
"""
import json, os, sys, time, urllib.error, urllib.parse, urllib.request

URL = os.environ.get("NSS_API_URL", "https://nsshq.com/api/v1/check?value=example.org")
KEY = os.environ.get("NSS_API_KEY", "")
STATE = os.environ.get("NSS_STATE", "nss-verdicts.json")


def request_url(value):
    u = urllib.parse.urlsplit(URL)
    q = urllib.parse.parse_qsl(u.query)
    q = [(k, value if v == "example.org" else v) for k, v in q] if any(v == "example.org" for _, v in q) else q + [("value", value)]
    return urllib.parse.urlunsplit(u._replace(query=urllib.parse.urlencode(q)))


def check(value):
    req = urllib.request.Request(request_url(value), headers={"Accept": "application/json", **({"Authorization": "Bearer " + KEY} if KEY else {})})
    while True:
        try:
            with urllib.request.urlopen(req, timeout=120) as r:
                return json.load(r), r.headers.get("NSS-Quota-Remaining")
        except urllib.error.HTTPError as e:
            body = json.loads(e.read() or b"{}")
            if e.code == 429 and e.headers.get("Retry-After"):      # per-minute limit: wait and try again
                time.sleep(int(e.headers["Retry-After"]) + 1)
                continue
            if e.code == 429:                                       # the day's allowance is spent: stop, keep what we have
                return {"stopped": body.get("resets_at") or "daily limit reached"}, "0"
            return {"error": e.code, "detail": body.get("error")}, None


def verdict(answer):
    return answer.get("band") or answer.get("label") or answer.get("verdict")


def main(path):
    items = json.load(open(path))["indicators"]
    old = json.load(open(STATE)) if os.path.exists(STATE) else {}
    new, changed = dict(old), False
    for it in items:
        if it["type"] not in ("domain", "ipv4"):                    # the check takes one domain name or one IP address
            continue
        answer, left = check(it["value"])
        if "stopped" in answer:
            print(json.dumps({"stopped": answer["stopped"]}), file=sys.stderr)
            break
        v = verdict(answer)
        row = {"value": it["value"], "type": it["type"], "verdict": v, "as_of": answer.get("as_of"), "previous": old.get(it["value"])}
        row["changed"] = bool(row["previous"]) and v != row["previous"]
        changed |= row["changed"]
        if v:
            new[it["value"]] = v
        print(json.dumps(row))
        if left == "0":
            break
        time.sleep(1.1)                                             # stays under a key's default 60 calls a minute
    json.dump(new, open(STATE, "w"), indent=1)
    sys.exit(2 if changed else 0)


if __name__ == "__main__":
    main(sys.argv[1] if len(sys.argv) > 1 else "nss-tk-01.json")

0 6 * * * cd /opt/nss && python3 nss_check_file.py nss-tk-01.json >> checks.jsonl || echo "NSS: a TK-01 verdict changed" | mail -s "NSS TK-01" [email protected]

git clone https://github.com/nsshq/nssresearch
# each paper's folder holds stix2.1-bundle.json, misp-event.json and iocs.csv

For managed phones: alert on the package com[.]anonymous[.]wallet and on the file's SHA-256 from the file table above, and allow wallet apps only from the official stores.

Timeline

1. 20 Jun and 3 Jul 2025
   quick-node[.]com and pt888999[.]com are registered, at two different registrars. They will receive the app's private keys and recovery phrases.
2. 1 Dec 2025
   ikunzf[.]online is registered. It becomes the first forwarding domain.
3. 25 Oct 2026
   NSS first resolves names of this shape forwarded through ikunzf[.]online. It takes them from public lists.
4. 7 Nov, 05:14:08
   Ten names of the shape are registered in the same second.
5. 7 Nov, by 16:37
   Public lists carry tokanix-cdn87-hk43[.]lol, a name of the same shape bought on 30 October. NSS has not yet recorded any of the 53.
6. 8 Nov, 04:16 to 04:17
   NSS records the 12 names of 7 November from the day's new registrations. They resolve through ikunzf[.]online to three of the four addresses.
7. 10 Nov, 00:52 and 16:21
   Two more purchases of ten names each, the first in one second, the second in two. Three names spelled like TokenPocket follow at 16:27.
8. 11 Nov, 04:47 and 04:57
   Two new forwarding domains, yumsihjkk[.]cc and shenswdns[.]cc, are bought ten minutes apart.
9. 11 Nov, 09:39 and 18:27
   Two more purchases of ten names, all behind yumsihjkk[.]cc and the address 82.158.231[.]42.
10. 12 Nov, 04:08
    NSS records those 20 names. Its first captures half an hour later see only the visitor check.
11. 12 Nov, from 05:20
    Older names, still under their ikunzf[.]online labels, begin to resolve to 82.158.231[.]42 as well.
12. 13 Nov, 00:43 to 00:55
    NSS loads the pages as a desktop, an Android phone and an iPhone and reads the imToken copy and its download links.
13. 13 Nov, 01:18
    NSS downloads the app and reads its code without running it: package com[.]anonymous[.]wallet, and the two names it sends wallet secrets to.
14. 13 Nov, from 06:56
    NSS records seven more names spelled like TokenPocket on 82.158.231[.]42. They are not counted in this paper.
15. 13 Nov, 11:06 to 11:07
    NSS resolves pt888999[.]com and api[.]quick-node[.]com: both on 195.245.242[.]143. A browser opening api[.]quick-node[.]com lands on the real provider's website.

The NSS tools used

• > Discovery

  Took all 53 names, and the 13 more of 10 November, from the daily lists of new registrations, between 4.3 and 26.2 hours after purchase, and resolved each through its forwarding chain.

• > Register

  Holds the four forwarding addresses as tracked hosts and classes them, and the address behind the app's two names, as dedicated.

• > Capture

  Made 23 capture attempts on 12 November between 04:38 and 05:33 UTC: 12 loaded a page (11 names), and every stored image shows the visitor check. On 13 November, loaded the pages as a desktop, an Android phone and an iPhone and read the imToken copy and its download links on 2 names; captured api.quick-node[.]com sending a browser to the real provider's site; downloaded the app file and read its code without running it.

• > Scan

  Re-checked where every name resolves on 13 November and read live certificates; a tool chain on Scan tied the two collector names to one address and read their registration records.

• > Family finder

  Grouped the names of the same shape around one of them and showed their purchase batches.

• > Investigate

  Read the public registration record of every name and forwarding domain and found the purchase bursts.

• > Hunt

  Searched NSS's library of past reporting for the same brand and method: four earlier reports, and no shared name, address or file.

Indicators

The first 25 of 75 indicators. Each is written defanged so it cannot be opened by accident. TLP:CLEAR. Use them in your own tools; no account needed.

How we know

What this rests on

• Where each name resolves and what it forwards to is from NSS's own resolution records from 8 to 13 November and one fresh check of every name on 13 November 2026 at 00:39 UTC. The two exfiltration names were resolved on 13 November at 11:06 and 11:07 UTC.
• The listing state was checked on 13 November 2026 at 14:31 UTC against every list NSS takes in. A listing of the name or of any web address on it counts.
• Registration times and registrars are public registration records, read on 12 and 13 November 2026. A burst is several names from one registrar in the same one or two seconds.
• Page descriptions are from NSS's 23 stored capture attempts on 12 November 2026 between 04:38 and 05:33 UTC (12 loaded, all at the visitor check) and from pages NSS loaded on 13 November 2026 between 00:43 and 00:55 UTC (the imToken copy, on 2 names). The app file was downloaded by NSS on 13 November 2026 at 01:18 UTC and read without being installed or run (SHA-256 66a22b70...ab26a, in full in the file table and the indicator list); the read, its manifest, signature and the code that sends each secret, is stored in NSS's records with the hash.
• The host type of each address is as NSS classed it on 13 November 2026 (103.38.82[.]202 from 10:26 UTC).
• NSS's stored captures of the pages are from 12 November 2026, and NSS loaded the pages again on 13 November. Every verdict in this paper is as read on 13 November 2026; the two collector names and their address are re-checked every 30 days.

What we cannot say

• NSS did not see how visitors are sent to the pages, who received the links, or whether anyone installed the app.
• NSS downloaded and read the app but did not run it, so what it sends is read from its code, not watched on a phone.
• 195.245.242[.]143 is an indicator as of 13 November 2026, where both exfiltration names resolved, not a claim about who runs it. NSS re-checks it every 30 days.
• The 53 are names NSS recorded itself. At least 2 names from the same purchases reached NSS only from lists, so NSS's record of this set is not complete.
• "On no threat list NSS takes in" is not "on no threat list anywhere". The 20 names bought on 11 November were about two days old at the check.
• The forwarding service may serve more than one customer. The Telegram and download look-alikes on it, and the seven TokenPocket names of 13 November, are not counted in this paper's numbers.
• This paper is not attributed to any named group. NSS-TK-01 is NSS's register name for this case, not a named group.

Use and citation

This paper is marked TLP:CLEAR: it may be shared without restriction. Cite as:

Nexus Sentinel Station (NSS), "Fake imToken download sites push an Android app that sends recovery phrases and private keys to one server: technical analysis", NSS-TK-01, 13 Nov 2026. https://nsshq.com/research/fake-imtoken-download-sites