◯Ghost in the Bit

A Second Opinion on the Server That Said "pls input someting"

threat hunting validation Threat hunting 15 min read
The findings I trust most are the ones two independent tools land on without ever comparing notes. I had already published the "pls input someting" investigation, a multi coin cryptojacking takeover running on a Beijing cloud, traced through the Censys Platform from a single careless open directory to a 27 server fleet. The case felt solid, and I believed it. However, a result that a second scanner reaches on its own, from its own data, is one I can stand behind a good deal harder, and the only way to earn that was to take the whole thing somewhere else and try to break it.

So I rebuilt it from scratch in Silent Push, a platform I had heard of but never used for real work before. I wanted to know three things. Did the fleet survive a different scanner with a different view of the same internet. Did the operator infrastructure look the same through a different lens. And what would a platform with its own scanners and its own history add to a case I already thought was finished. The honest answer to all three is more interesting than a clean win, because the case went deeper, one signature behaved differently here and sent me looking for a better one, and the platform handed me a piece of history the public record no longer shows.

The short version

A different set of eyes

Silent Push runs its own scan and Domain Name System (DNS) collection, and you query it with a small language called SPQL. The grammar is straight forward enough. You write field operator value, separate the clauses with spaces, and join them with AND. There is no OR keyword, though a bracketed list on one field acts like one. You aim each query at a repository with datasource =, and for the web side the ones that mattered to me were webscan for the host responses, services for the banner and key data, opendirectory for raw listings, and whois for registration.

One thing to know before you start, because it cost me a few minutes of confusion. The hashes do not port. Silent Push computes its own fingerprints its own way, so the Censys hash I carried in from the first investigation matches nothing here. For anything hash shaped, the host fingerprint, the body hash, the Secure Shell (SSH) key fingerprint, you open a known host first, read the platform's own value off its record, and pivot on that. Paste a foreign hash and you will get a clean and very convincing zero.

The anchor, and what each scanner captured

I started where the whole case started, the open directory at 101.126.33[.]186, the build bench that had been serving the toolkit. In Censys that host answered on port 9999 with a raw listing, which is the single thread the entire investigation hangs from. I asked Silent Push for the same thing. 

ip = 101.126.33.186 AND datasource = opendirectory

Nothing. Zero results, and the reason is ordinary. Scanners sweep enormous stretches of the internet and sample ports as they go, so any two platforms will have caught a given host on different services at different moments. Silent Push's record of this machine had captured its SSH service rather than the directory port, which looks at first like a miss and turns out to be a gift, because the SSH side is exactly what I needed next.

What the platform did have on the anchor was its SSH side.

ip = 101.126.33.186 AND datasource = services

Four records, all the same OpenSSH banner, and with them the host's RSA key fingerprint in Silent Push's own format.

fingerprints.RSA = "SHA256:xzBUOdt2tM/wmFtyes+jtRZq6xE/CQMBoXH/cULs0i8"

In the first investigation an SSH key is where I nearly fooled myself, betting a shared host key would tie a fleet together and instead pulling back 13,736 cloned cloud images. So I ran this one out of habit, half expecting the same trap. It pivoted to exactly two records, both the anchor itself. This key belongs to one box and one box only. The payload origin I check later carries its own unique key as well. On this platform, for these hosts, the SSH key tracks an individual machine rather than linking the estate, which is the opposite failure mode from the one that nearly caught me before, and a useful reminder that the same field can be a trap on one host and a clean tracking signal on another. You learn which by testing it, never by assuming.

The fleet, and finding the right signature

Now the heart of it. In Censys I isolated the fleet on one detail, the realm string in the WWW-Authenticate header. 

WWW-Authenticate: Basic realm="pls input someting"

An nginx basic auth prompt has no default text. The operator has to supply that string, so a realm is always a deliberate choice, and this one is a careless choice made once and never corrected, pls input someting, misspelled and worn byte for byte by every server the operator built. The first thing I confirmed in Silent Push is that the platform captures it too. Open any fleet host and it is right there in the record. 

header.www-authenticate = Basic realm="pls input someting"

Silent Push returns a great deal in every record and indexes a specific set of fields for searching, and those two sets are not identical. The realm is among the values it returns and displays. When I aimed a query straight at it, by exact value and by wildcard both, the index answered the same way each time, because the realm sits outside the searchable set. 

Please enter a valid query.

Their published field reference spells out which header fields are searchable, server, content-type, content-length, connection, cache-control, etag, refresh, and x-powered-by, and the realm is returned rather than among them. That is not a dead end, it is a signpost. It told me the realm would be my confirmation rather than my selector, and pointed me toward the indexed field that was rare enough to stand in for it. So I went looking for another road to the same 38 hosts.

The obvious road is the page itself, and it is a trap. Every fleet host answers with the same tiny 401, and the platform offers several hashes of that reply. I read the fuzzy hash off a known host and searched it. 

html_body_ssdeep = "3:qVZxQXbZ6iF4:qzxO965" AND datasource = webscan
→ 58,528,679

Fifty eight million hosts. Constraining that to the operator's own network barely helped.

html_body_ssdeep = "3:qVZxQXbZ6iF4:qzxO965" AND geoip.asn = 137718 AND datasource = webscan
→ 12,367

The header fingerprint did no better, and it is worth being precise about why. Silent Push computes a value it calls the HHV, and its own field reference defines it as a hash based on the header keys, the set of header names a host returns rather than their values. The whole fleet shares one, so I had high hopes for it. 

HHV = "0fa1cddc4cff3d1e2bcc952a40" AND datasource = webscan
→ 1,789,640

HHV = "0fa1cddc4cff3d1e2bcc952a40" AND geoip.asn = 137718 AND datasource = webscan
→ 972

Almost two million worldwide, and the 972 left inside the operator's network were not the fleet. They were a grab bag of unrelated services that happen to return the same little 401, a Prometheus instance, admin panels on 8080 and 8081 and 8888, a spread of nginx versions from 1.14 to 1.29 and openresty besides. My fleet was uniform nginx/1.16.1 on port 80. These were not it.

This is the exact lesson the first investigation drilled into me, arriving again in a new costume. Two different hashes, two different reasons neither one helps. The body hash matches because the login page is the stock nginx 401 that every nginx box on earth returns when it refuses a login. The header hash matches because every one of those boxes also presents the same set of header names. The misspelled realm is in there both times, as a header that exists and as a value on the page, and neither hash captures the one thing that was actually the operator's, the wording inside it. So the productive question became a simple one, which indexed field is rare enough, inside this network, to stand in for the typo.

The rebuild that held

The answer was hiding in the part of the response I had been treating as background. The fleet does not just share a 401. It shares an old server build, nginx/1.16.1, a 2019 release that is uncommon now, and the operator deployed it uniformly on port 80. A rare version, pinned to a port and a response code inside one autonomous system, is specific in a way the body never could be. 

header.server = "nginx/1.16.1" AND response = 401 AND port = 80 AND geoip.asn = 137718 AND datasource = webscan

That is the rebuild. I pulled the full result and deduplicated it by host, and across nearly three hundred scan records reaching back to mid 2025 it collapsed to 38 distinct machines. Every single row carried nginx/1.16.1, port 80, a 401, and, returned in the record where I could read it, Basic realm="pls input someting". Not one false positive in the entire set. The realm did the confirming, riding along on every row to vouch for the host the query had already caught.

Thirty eight distinct hosts. The 27 from the original investigation were all in there, and Silent Push's scan data carried the live cluster more completely at the moment I looked, which is what you expect when two independent scanners on their own sweep schedules each sample a cluster that has been growing since the summer. Both Beijing hosts came back, 180.184.54[.]173, the one running the Uptime Kuma monitor pointed into the fleet, and its neighbor 180.184.54[.]253. So did the two nodes I had named from the other side of the investigation, 115.190.140[.]175, the payload origin written into line 10 of the malware, and 115.190.62[.]231, the relay hardcoded in a configure script. The case did not just survive the move to a second platform. It came out the other side fuller and confirmed.

I want to be exact about one limit, because the restraint is the point. This four part query is operator exclusive in practice, proven by the realm appearing on all 38 hosts, not because an old nginx on port 80 could never belong to someone else. The realm typo is still the thing that says these machines are one operator's. It simply does the work from the passenger seat now, confirming rather than selecting.

What the history showed

The original investigation gave me the fleet as a snapshot, the cluster as it stood the week I found it. Silent Push keeps the scan history, and reading the dates turned that snapshot into a timeline.

Two hosts, 115.190.12[.]165 and 115.190.15[.]120, have been answering with this exact fingerprint since late June 2025. The other 36 do not appear until November and December. So this was not a fleet that materialized the week I happened to find it. It had a two host core running the same misspelled realm for roughly five months, quietly, before the operator scaled it out into the cluster I eventually caught. On a platform built around the idea of indicators of future attack, the kind of behavioral signal you watch before it is weaponized rather than after, that is the whole argument in one timeline. The tell was sitting in the data, searchable through the server build, half a year ahead of the buildout. Nobody was watching for it yet. The point of a platform like this is to be the thing that was.

The domains, and what the platform's history added

In the published investigation I had to leave one thread honestly unfinished. The operator used two domains, hd3p[.]com and http33[.]com, and I could tie them together by how they were used but not by any clean record of shared ownership. Registration data is exactly where a passive DNS and WHOIS platform should earn its keep, so this is where I pushed. 

domain = hd3p.com AND datasource = whois

hd3p[.]com came back created on 19 December 2012, registered through Alibaba Cloud Computing in Beijing. That matches what I already knew. Then http33[.]com. 

domain = http33.com AND datasource = whois

Its current record is unremarkable, a 2023 registration sitting behind Cloudflare nameservers. The history is where the platform showed me something the live public record no longer does. Silent Push retained an earlier life for this domain, a registration from 28 December 2018, through Alibaba Cloud Computing in Beijing, on reg.cn nameservers, out of Jiangxi, that lapsed in 2019 before the domain was re-registered on Cloudflare years later. The nameserver hashes the platform keeps for tracking configuration changes tell the same story of three separate lives. 

http33.com   2018  Alibaba / reg.cn     nshash 271868d2311a735f6b06e2856da57b83   (lapsed)
http33.com   2023  Hostinger parking    nshash 445baadf45f7dc1cb60f1ff0163361d8
http33.com   2023  Cloudflare           nshash be94bb8075b663eb9d1078c1754c5be6   (current)

Here is the discipline, because this is exactly the kind of result that wants to be more than it is. The retained 2018 history places http33[.]com in the same Alibaba Beijing milieu that hd3p[.]com has lived in since 2012. That is a real and genuinely useful detail, and the public record will not give it to you anymore. However, it is not proof the two domains share an owner. Alibaba is the dominant registrar across this entire region, a lapsed domain is routinely picked up by someone unrelated, and the three nameserver hashes do not match each other, let alone hd3p[.]com's. So the link between the two domains stays exactly where I left it in the first writeup, established by use and unproven by registration. What changed is that I can now say so with the help of additional data. The platform did not hand me the link. It handed me a sharper, deeper documented reason that the link remains unproven, which in this work is its own kind of progress.

From queries to monitors

There is one more thing the rebuild made obvious, and it is the part that makes the whole exercise worth more than a reproduction. The same expressions save as monitored queries that alert the moment a new match appears. The fleet rebuild, the open directory mirror catch, a watch on the operator's domains, each one stops being a thing I check and becomes a thing that tells me. A query finds the fleet that exists today. A monitor is waiting for the thirty ninth host the night it comes online. That shift, from a query you run to a tripwire you set, is the difference I came to understand by doing this rebuild rather than reading about it.

What I am claiming, exactly

The same restraint I held the first time applies here, so let me be exact.

I have shown that the fleet reproduces on an independent platform, and that Silent Push's data added more to it than my first snapshot at the time of investigating, 38 hosts rather than the 27 I documented, every one carrying the misspelled realm. The fuller count is real coverage, not a looser query, because the realm confirms each host the rebuild catches.

I have shown that the operator's core has been live since at least June 2025, from the platform's retained scan history, and that the buildout into the full fleet followed months later.

I have shown a lapsed 2018 Alibaba registration on http33[.]com that the live public record no longer carries, and I am explicitly not calling it proof of shared ownership with hd3p[.]com. It is suggestive context that leaves the link where it was, unproven by registration.

I am noting two neutral facts about how the platform captured this particular case, that its scan of the anchor recorded the SSH service rather than the directory port, and that the realm sits among the returned fields rather than the indexed ones. Neither changed the outcome, and both shaped the path I took to it.

I am not restating the malware analysis here. The takeover chain, the backdoor, the relay backbone, all of that stands on the original investigation and its operator source files. This piece is about whether the infrastructure holds up under a second set of eyes, and it does.

What you can use

The queries below carry live values so they actually run on the platform. The host inventory at the end is defanged, so nothing in that block is clickable.

Rebuild the fleet. Returns the operator's machines, clean, today.

header.server = "nginx/1.16.1" AND response = 401 AND port = 80 AND geoip.asn = 137718 AND datasource = webscan

If the autonomous system number ever behaves oddly, match the organization name instead.

header.server = "nginx/1.16.1" AND response = 401 AND geoip.as_org ~= /Volcano/ AND datasource = webscan

Do not pivot on the generic hashes. These are the traps, recorded so you do not repeat them.

html_body_ssdeep = "3:qVZxQXbZ6iF4:qzxO965"          → 58,528,679   (the stock nginx 401 body, the whole internet)
HHV = "0fa1cddc4cff3d1e2bcc952a40"                    → 1,789,640   (the stock 401 header set, not the realm value)
HHV = "0fa1cddc4cff3d1e2bcc952a40" AND geoip.asn = 137718   → 972    (unrelated 401 services, not the fleet)

Settle the domains as far as the data allows.

domain = hd3p.com AND datasource = whois
domain = http33.com AND datasource = whois

Stand the signatures up as monitored queries so they alert on new matches rather than waiting to be rerun.

The fleet (38 hosts, defanged, all Volcano Engine / AS137718)

101.126.14[.]111    101.126.55[.]16     101.126.67[.]212    101.126.75[.]89
101.126.78[.]183    101.126.84[.]193    101.126.88[.]177    101.126.89[.]153
101.126.136[.]14
115.190.12[.]165*   115.190.15[.]120*   115.190.55[.]231    115.190.59[.]140
115.190.62[.]231    115.190.73[.]18     115.190.73[.]51     115.190.73[.]180
115.190.73[.]240    115.190.74[.]110    115.190.74[.]144    115.190.74[.]200
115.190.74[.]225    115.190.75[.]101    115.190.76[.]87     115.190.76[.]118
115.190.76[.]254    115.190.77[.]205    115.190.79[.]142    115.190.115[.]35
115.190.134[.]24    115.190.140[.]175   115.190.166[.]126   115.190.171[.]165
115.190.174[.]228   115.190.174[.]229   115.190.174[.]230
180.184.54[.]173    180.184.54[.]253

The two hosts marked with an asterisk, 115.190.12[.]165 and 115.190.15[.]120, are the long lived core, present since late June 2025. 115.190.140[.]175 is the payload origin named in the malware, 115.190.62[.]231 is the hardcoded relay, and 180.184.54[.]173 runs the Uptime Kuma monitor on the operator's own domain.

Closing

I went into this expecting either a clean reproduction or an embarrassing one, and I got neither. The fleet did not just survive the move to a second platform, it came through fuller, and the history I could not see the first time showed a quiet core running for months before the operator scaled up. The signature that made the original hunt easy played a different role here, the realm typo riding along as confirmation while a rare server build did the selecting. The big internet wide hash numbers tried to fool me all over again, fifty eight million hosts on one of them, and the work was the same as it has always been, the patience to set the exciting number down and reach for the rare one instead.

That is the part I trust most about both versions of this investigation. The two platforms saw the case from different angles, and the discipline that held me honest did not change between them. A second platform deepened the picture, not because it was magic, but because I made it answer the same hard questions the first one did and refused to let a smaller, looser claim stand in for the one I could actually prove. Checking your own work on unfamiliar ground is uncomfortable, and it is the only way I know to find out whether what you believe is true or merely familiar. This case is truer to me now than it was when I published it, and the parts that are still unproven are unproven in writing, on purpose, which is exactly where I want them.

A note on method. The infrastructure rebuild, the host fingerprint and SSH key checks, the body hash comparisons, and the WHOIS and history work all ran inside the Silent Push platform. Where a value is a platform computed hash, I read it off a known host on the platform rather than importing a foreign hash, and I have noted that throughout. The network indicators in the inventory block are defanged. This piece validates and extends the infrastructure findings of the original "pls input someting" investigation, which carries the full malware analysis and operator source.

Powered by Buttondown.