One wallet-phishing operator, six servers in three weeks: followed by the names it carried host to host

Key findings

1. One operation, six servers. NSS's own resolution record shows the same names resolving to six addresses between 27 October and 14 November 2026: 94.26.106[.]72 (27 to 31 October), then 103.38.82[.]152, 103.38.82[.]202, 156.225.24[.]233 and 156.225.24[.]119 side by side (1 to 10 November), then 82.158.231[.]42, the server of the NSS-TK-01 paper, from 11 November. 104 names in all: 103 registered names and one forwarding label.
2. Twenty-four names moved. Each was seen on two or more of the six servers, in date order. Six went the whole way: telegramorg-cn[.]co, telegramorg-cn[.]com, mtoken-im[.]cv and three telergam-cdn names under aa9977rt[.]com went from the first server on 31 October to a middle server on 6 November (the third, fifth, second or fourth) and to the sixth on 12 November. Four more went from the first server to a middle one; seven relay-shaped wallet names and one Telegram look-alike moved among the middle servers between 1 and 8 November; six went from a middle server to the sixth on 12 November. Wallet, Telegram and mtoken names moved on the same days to the same servers.
3. Twenty-two of the 24 moved behind the forwarding layer. Each of them kept one label under the forwarding apex while the address behind it changed: telegramorg-cn[.]co pointed at its label under ikunzf[.]online from 31 October to 12 November while it resolved to the first, the third and then the sixth server. Whoever runs the forwarding chose every server for those names. The other two, mtoken[.]online and mtoken[.]download, have no forwarding record; their own records changed.
4. The forwarding apexes look like the operator's own. ikunzf[.]online (bought 1 December 2025), yumsihjkk[.]cc and shenswdns[.]cc (bought ten minutes apart on 11 November 2026 at 04:47 and 04:57 UTC) sit at one registrar and use the same two hosted name servers. In NSS's record nothing resolves under them but this operation's names and four fake-software download names. Under five hours after yumsihjkk[.]cc was bought, ten relay-shaped names were bought behind it, and on 12 November the three telergam-cdn names were re-pointed to the same label, atzuqs2x, under the new apex.
5. What the lists carried, and when. Of the 104 names, 34 were on a threat list NSS takes in on 14 November 2026. Thirty of the 34 were on a list on or before the day NSS first saw them on a server of the chain; four were listed one to three days after. The names new to the chain at each server were listed 13 of 13, 4 of 4, 10 of 19, 5 of 10, 2 of 15 and 0 of 43. The 7 listed names on the current server are the six that went the whole way and one moved name.
6. The operation is older than NSS's record of it. The carried names were bought between 13 July and 10 September 2026 at three registrars other than the one that holds the rest, and were on lists from 2 August; the first server's address has been on a list since 6 July. All 13 names of the first server entered NSS's record from lists. From the third server on, NSS's own sensors recorded most new names first, from new registrations and certificate logs: 13 of 19 on the third server, 5 of 10 on the fourth, 7 of 15 on the fifth and 37 of 43 on the sixth; 62 of the 104 in all, 58 of them on no list on 14 November.
7. The forwarding layer also fronted fake-software downloads. Three names that threat lists carry as malware-download hosts, download[.]google-chrome[.]cyou (list date 15 March 2026), download[.]tfyxzai[.]com (6 August) and download-sougou[.]com[.]cn (31 August), pointed at labels under ikunzf[.]online when NSS first resolved them, between 25 October and 1 November; a fourth, app[.]app-lestalk[.]com[.]cn, joined on 10 November. On 26 and 27 October one address, 93.152.221[.]188, answered for download-sougou[.]com[.]cn and a relay-shaped wallet name together. They did not move with the chain, and the paper does not attribute them to the operator.
8. Host types and verdicts. NSS classes the four later servers as dedicated hosts: every name NSS saw on them fits this forwarding set, though NSS cannot rule out other customers of the forwarding. Investigate and Scan agree on all 116 indicators in this paper: High risk for the four later servers, the two labels, 102 of the 103 names and three of the four download names; Suspicious for the first two servers, the apex yumsihjkk[.]cc, one name and one download name. The older apex ikunzf[.]online reads Clean on both surfaces because its labels no longer resolve to an address; it is named in the body and left out of the indicator list.

How an analyst finds this with NSS

The same case, worked the way a defender works it in NSS: from the current server back to the first server in NSS's record, then forward to the thing to watch. Every picture is the real Station on 14 November 2026, cropped to the panel in use.

1. 01Step 1. Start from the server in the NSS-TK-01 paper. Investigate rates it High risk, shows NSS's register entry for the operator with its sibling servers, and lists the names seen on it; the red chips are the seven a threat list carries.

   

2. 02Step 2. Open one of the red chips on Scan. telegramorg-cn[.]co has been in NSS's catalogue since 31 October and has three addresses on record: the first server, a middle one and the current one. That is a name moving host to host.

   

3. 03Step 3. Open a forwarded name. Its casefile shows the alias chain: the name points at its own label, atzuqs2x, under the forwarding apex, and on 14 November that label pointed at a shared host label that gave the address. The three telergam-cdn names were re-pointed to the same label under the new apex on 12 November, a day after it was bought.

   

4. 04Step 4. Widen one relay-shaped name to its family. The family finder returns every registered name of the same shape, with how many a list carries.

   

5. 05Step 5. Run a tool chain on the forwarded name: the addresses and aliases NSS has on record for it, then every name NSS has seen on those addresses. Two steps give the three servers it sat on and the 84 names that shared them.

   

6. 06Step 6. Then act: watch the server, watch the whole operator from the register card, 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-tl-01.json)   # the first indicator in the paper's file
curl -s "https://nsshq.com/api/v1/check?value=$NAME"

{
  "as_of": "2026-11-14T20:41:48Z",
  "band": "Suspicious",
  "band_is_host_class": false,
  "found": true,
  "host_class": {
    "class": "unknown",
    "label": "Host type unknown",
    "sentence": "No address on record for this name."
  },
  "known_good": false,
  "names": null,
  "public_listing": { "state": "not_checked", (...) },
  "reports": 0,
  "type": "domain",
  "value": "yumsihjkk[.]cc",
  "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-tl-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:
            try:
                body = json.loads(e.read() or b"{}")
            except ValueError:                                      # an error page that is not JSON
                body = {}
            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-tl-01.json")

0 6 * * * cd /opt/nss && python3 nss_check_file.py nss-tl-01.json >> checks.jsonl || echo "NSS: a TL-01 verdict changed" | mail -s "NSS TL-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

At the DNS layer the cheapest control is the forwarding apex: block yumsihjkk[.]cc and any name that resolves through it. Any server the operator wires behind that apex is covered by the same block; names on the old apex or with no forwarding record need the address block too.

Timeline

1. 1 Dec 2025
   ikunzf[.]online is registered. It becomes the first forwarding apex.
2. 15 Mar 2026
   download[.]google-chrome[.]cyou, a fake-software download name that will later sit under the apex, is listed as a malware-download host.
3. 6 Jul 2026
   94.26.106[.]72, later the first server in NSS's record, is on a list.
4. 13 Jul to 10 Sep 2026
   The names the operation will carry from server to server are bought at three registrars: telegramorg-cn[.]com, telegramorg-cn[.]co, mtoken-im[.]cv, then the two mtoken names. They are on lists from 2 August.
5. 6 and 31 Aug 2026
   Two more download names, download[.]tfyxzai[.]com and download-sougou[.]com[.]cn, are listed as malware-download hosts.
6. 14 Oct
   The first relay-shaped wallet name of the family is listed.
7. 25 to 27 Oct
   NSS first resolves names forwarded through ikunzf[.]online, from public lists: eight relay-shaped wallet names and one other name on two addresses, and three download names under labels of the apex.
8. 27 Oct
   The first name of the chain, tokevim-cdn32-hk61[.]lol, resolves to 94.26.106[.]72 and is listed the same day.
9. 31 Oct
   Twelve more names arrive on the first server: wallet, Telegram and mtoken names together, among them the three telergam-cdn names on the atzuqs2x label. Ten of them were on lists since August or September; two are listed that day.
10. 1 to 3 Nov
    The operation spreads over four servers in two networks. Names already on lists since 18 to 22 October join them.
11. 6 to 8 Nov
    The carried names move to the middle servers, keeping their labels; wallet names move among the four. NSS's own sensors start recording the new names first.
12. 10 Nov
    Last day a name of the operation is seen on any of the middle servers.
13. 11 Nov, 04:47 and 04:57 UTC
    yumsihjkk[.]cc and shenswdns[.]cc are bought ten minutes apart at the apex's registrar. Ten names are bought behind yumsihjkk[.]cc at 09:39 UTC, and the first names appear on 82.158.231[.]42, the sixth server, the same day.
14. 12 Nov
    The three telergam-cdn names are re-pointed to atzuqs2x under yumsihjkk[.]cc. The carried names resolve to the sixth server; eleven names on it still use their ikunzf[.]online labels.
15. 13 Nov
    NSS publishes NSS-TK-01 on the sixth server's fake imToken sites and app.
16. 14 Nov
    NSS reads the chain back from its own records: 104 names, six servers, 24 moved names, 34 listed.

The NSS tools used

• > Investigate

  Read the casefile of the current server, of every moved name and of the forwarding labels; its alias-chain finding showed the two-hop forwarding and its register card the operator's sibling servers.

• > Scan

  Re-read every indicator on 14 November so that Investigate and Scan agree; its infrastructure panel listed the addresses on record for each moved name.

• > Tools

  Chained two reads of NSS's own records over a forwarded name: its addresses and aliases on record, then every name seen on those addresses.

• > Family finder

  Widened one relay-shaped name to the 123 registered names of its shape and their listing state.

• > Register

  Holds the four later servers under NSS-TK-01 and classes them dedicated.

• > Discovery

  Recorded 62 of the 104 names first, from new registrations and certificate logs; 58 of them were on no threat list on 14 November.

Indicators

The first 25 of 116 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

• Which name resolved to which server, and on which days, is NSS's own resolution record, read on 14 November 2026 at 20:36 UTC. A move is a name with records on two or more of the six servers whose first days are in order.
• The listing state was checked on 14 November 2026 at 20:36 UTC against every list NSS takes in. A listing of the name or of any web address on it counts. A listing date is the date the list gives for the indicator, not the day NSS took the listing in.
• The forwarding labels are the alias answers stored in the same resolution record. The label-to-label hop was read from a fresh resolution through Investigate on 14 November (atzuqs2x[.]yumsihjkk[.]cc to z6pnwmjk[.]yumsihjkk[.]cc to 82.158.231[.]42); it is not in the stored record.
• Registration dates and registrars are public registration records read by NSS on 13 and 14 November 2026; name-server pairs are from NSS's zone data.
• The host type of each server is as NSS classed it on 13 and 14 November 2026. Every verdict in this paper was read on Investigate (page stage skipped) and then on Scan on 14 November 2026 between 20:38 and 21:41 UTC; the indicator list holds only indicators on which both agree at Suspicious or higher.
• The sixth server's pages and app are described in NSS-TK-01, from NSS's captures and download of 12 and 13 November 2026; this paper adds no new capture.

What we cannot say

• NSS's certificate-log intake has been behind since 13 November 2026 01:33 UTC and was still catching up when this paper was read, so names that appeared only in certificate logs after that time may be missing from the counts. The resolution record, zone data and list store were current.
• The record starts where NSS's data starts, on 25 October. The operation is older: its carried names were bought from July. The first server's names, the earlier addresses of 25 to 27 October and the download names reached NSS from public lists; names the operator used before then, or on servers NSS never resolved a name to, are not counted.
• A move is read from first and last days in NSS's record, which depend on when NSS resolved each name; a name may have moved a day earlier or later than the record shows. Two records on the same day may be one name answering with several addresses, not a move.
• Hosts 2 to 5 overlapped, so the chain is not a strict sequence, and the paper does not claim a cadence of moves.
• The download names share the forwarding layer and, for two days, an address with a wallet name; they did not move with the chain, and the paper does not attribute them to the operator. The carried names and the batch-bought names may have different holders who share one forwarding service.
• "On no threat list NSS takes in" is not "on no threat list anywhere". The 43 names new on the current server were under a week old at the check.
• This paper is not attributed to any named group. NSS-TK-01 is NSS's register name for this operation, not a group.

Use and citation

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

Nexus Sentinel Station (NSS), "One wallet-phishing operator, six servers in three weeks: followed by the names it carried host to host", NSS-TL-01, 14 Nov 2026. https://nsshq.com/research/wallet-phishing-host-lineage