The First Move: What Attackers Do the Instant They Are In

TI-2026-075F · The Armory, Part F Confidence: HIGH — direct honeypot evidence (106 commands across 88 IPs) + multi-source corroboration Classification: TLP:WHITE

The one word that gives them away

There is a moment, in every intrusion, that the attacker cannot skip. The credentials have worked. The shell has opened. The prompt is blinking. And before the payload, before the persistence, before the pivot — the intruder has to answer a question the defender already knows the answer to: who did I just become?

They answer it by typing whoami.

In the honeypot's record, whoami is the single most common post-login command: 106 executions across 88 distinct source IPs, spanning March through June 2026. No other command comes close to that spread of independent origins. Different countries, different toolkits, different intentions — and the same one-word first move, over and over, from operators who have never coordinated and never will. It is the most reliable behavioural signal of a successful unauthorized login that exists, and it is reliable precisely because it is involuntary. The attacker arrives without knowing what account the stolen key belongs to. The legitimate administrator never has that problem. She knows who she is; she logged in as herself. The intruder has to ask.

This dossier is about that instant — the first sixty seconds after a login succeeds. The Armory series has, until now, been a census of tools: what the 12,000 attackers carry (Part A), the cloud they rent it from (Part B), the operators who run two hands at once (Part C), the C2 frameworks at the heavy end (Parts D and E). This part turns from the weapon to the hand that holds it, and asks a narrower, more useful question. Not what do they bring — but what do they do the moment they are inside? Because that behaviour, unlike the tooling, is remarkably consistent across the whole attacker population, and consistency is what a defender can detect.

Orientation: the involuntary first move

The post-login command record sorts, cleanly, into a small number of behavioural phases. The first is orientation, and whoami is its signature.

It rarely travels alone. It arrives in a small, stereotyped bundle: whoami; id; uname -a; hostname. Four questions asked in a breath — who am I, what can I do, what kind of machine is this, what is it called. Sometimes pwd and cat /etc/os-release join them. This is the intruder building, from nothing, the situational picture that a legitimate user already carries in their head. The reason it is so uniform across unrelated actors is that the information deficit is uniform: every attacker who lands via a stolen or brute-forced credential arrives blind, and there are only so many ways to open your eyes on a Linux box.

For the defender, this uniformity is the entire opportunity. Consider what whoami as a session's opening command actually means. On an interactive workstation used by a human, it is faintly plausible — people occasionally check. On a service account, on a database host, on a router, on any machine where an interactive login is itself rare and an interactive login that begins by asking who it is is rarer still — it is almost diagnostic. The command is cheap to log, low in volume, and high in precision. It fires at the exact moment control changes hands. If a defender could watch for only one thing on a fleet of servers, "a session whose first command is whoami or id" would be one of the highest-yield single signals available, because it inverts the attacker's own blindness into the defender's alarm.

The lesson of the orientation phase is quiet but important: the most detectable thing an attacker does is the thing they cannot avoid doing. You do not need to recognise their tool. You do not need to fingerprint their malware. You need only notice that someone, having just logged in, does not know who they are.

Counter-surveillance: when the watched checks for the watcher

The second phase is stranger, and it is where the honeypot watches the attacker try to detect the honeypot.

A recurring routine — present in a meaningful minority of sessions — is honeypot self-detection. Before committing anything, the more careful operator tests whether the "host" they have landed on is in fact a sensor recording them. The checks are a catalogue of the defender's own tools turned into the attacker's tripwire list:

• A grep of /etc/passwd for the username phil — the default account baked into the Cowrie SSH honeypot. Its presence is, to an attacker who knows the tell, a confession.
• A scan of the process list for honeypot software by name: cowrie, kippo, dionaea, honeytrap, opencanary, glutton, heralding.
• A look at the well-known install directories those tools ship in.
• A stat of core binaries — /bin/ls, /bin/sh — checking sizes and inodes for the tell-tale signatures of an emulated shell rather than a real one.

This is counter-surveillance. The intruder, before they will spend a payload, wants to know if the payload will be captured. And the fact that they bother is itself a finding with two edges.

The first edge is a validation. Attackers screen for honeypots because honeypots work — because a captured session is a real cost to them: a burned tool, a fingerprinted technique, an IOC handed to defenders. If sensors were toothless, no one would look for them. The screening is the adversary paying the honeypot the compliment of treating it as a threat.

The second edge is a gift. On a real host — a production server that is not a honeypot — no legitimate user ever greps their own passwd file for phil, or scans the process table for dionaea, or stats /bin/sh to check whether it is emulated. That behaviour has exactly one meaning. So the very check the attacker runs to avoid detection becomes, on genuine infrastructure, one of the highest-fidelity intrusion indicators a defender can deploy. You detect the intruder by detecting their fear of being detected. The honeypot, in capturing the anti-honeypot check, closes a small, satisfying loop: the watcher records the watched checking for the watcher.

Fingerprinting: the target's identity selects the payload

The third phase is the most methodical, and it dispels a comfortable myth — that automated attackers are dumb, that they blindly spray the same malware at everything. The evidence says the opposite. Before persistence, a structured reconnaissance sweep runs, and its purpose is a decision: what is this box for?

The sweep probes, in a recognisable order:

• Device class. Signatures for embedded and network gear — /system resource print (MikroTik RouterOS), /etc/openwrt_release (OpenWRT), /etc/version (Ubiquiti). The intruder wants to know if they have landed on a router or an IoT device rather than a general-purpose server, because that changes everything downstream.
• Capability. The presence of tunnelling and pivot tools — socat, chisel, gost, ncat. The state of the SSH daemon's forwarding settings — AllowTcpForwarding, PermitTunnel, GatewayPorts. Whether this machine can be made into a relay.
• Reach and privilege. Listening ports, the available package manager, whether sudo is present, which paths are writable.
• Architecture. uname -m, so the second stage can be built for the right instruction set.

Each probe narrows a decision tree, and at the leaves of that tree are different second stages. A router that forwards traffic becomes a pivot. An IoT device with an idle CPU becomes a botnet node. A server with sudo and writable paths becomes a miner or a staging host. The same intrusion script produces different outcomes because the target's identity, discovered in this phase, selects the payload. This is why the persistence stage — as we will see — pulls a multi-architecture binary: the operator does not know in advance whether they will need the x86 build or the arm64 build, so the reconnaissance decides, and the download matches.

For the defender, the fingerprinting phase is the last quiet interval before the storm. Nothing has been installed yet. No account has been backdoored. But the commands are unmistakable — a login session that reads /etc/openwrt_release, checks AllowTcpForwarding, and enumerates writable paths is not doing anything a legitimate user does. Detecting the fingerprinting buys the one thing incident response never has enough of: the interval before the payload lands.

Persistence: the fingerprint that betrays a family

The fourth phase is where control is cemented, and it is where the honeypot's data ties this dossier back into the rest of the Armory.

The persistence repertoire is commodity but effective. Backdoor accounts are created with fixed, unimaginative names — admin1, user1 — and added to the sudo group, granting the operator a durable, privileged way back in that survives a password change on the original compromised account. And the credentials are reset to a shared marker string: modzmodz.

That marker is the single most useful artefact in the whole post-login record, and the reason is a mistake the operator did not know they were making. A password reused across every host in a botnet is not a secret — it is a fingerprint. The same string, appearing in the persistence stage of otherwise-unrelated compromises across different IPs and different weeks, ties them all to one operator's toolkit. The modzmodz botnet family is legible precisely because its author was lazy about credentials, and the laziness that helps the operator manage a sprawling fleet is the same laziness that lets a defender cluster the whole fleet into a single campaign. The reused password is the thread; pull it, and the botnet unravels into one hand.

The persistence chain then reaches out for its real payload. It pulls a second-stage binary — the family the honeypot data labels meow, shipped in both an x86 build and an arm64 build, matching whatever the fingerprinting phase found — from a fixed host: 35.237.91.38.

That address resolves to Google Cloud, AS396982.

Which is the same hyperscaler that TI-2026-075B, The Cloud Contractor, identified as the concentration point for the honeypot's pentest tooling — the disposable cloud where the scanners and the credential-guessers cluster. Two letters of this series, approaching from two different angles, land on the same network. The reconnaissance tooling and the payload staging rent the same ground. The offense's supply chain and its delivery chain are the same rented, disposable, reputation-free cloud — observed once from the scanner's side and once from the payload's side, and revealed by the census to be a single substrate. The loop between 075B and 075F closes on a single ASN.

The channel that hides in plain sight

There is a fifth phase, seen in the freshest samples, and it is the one that should worry a defender most, because it is the persistence-side mirror of this entire series' thesis: attackers hide inside trust.

A July 2026 sample installed a lightweight control implant that took its orders not from a hardcoded C2 server on some flagged bulletproof range, but from the Telegram Bot API. The implant polls Telegram for commands and reports the compromised host's identity back to a fixed chat. The command-and-control channel rides a legitimate, TLS-protected, globally-reachable, rarely-blocked consumer messaging service.

Think about what that defeats. IP reputation is useless — the endpoint is api.telegram.org, which is not on anyone's blocklist and cannot be without breaking a service millions of people use legitimately. TLS inspection is hard and often absent. The traffic blends into the noise of a world that talks to Telegram, Discord, Slack, and cloud APIs all day long. The C2 is not hiding in the dark corners of the internet; it is hiding in the well-lit centre, inside exactly the services a corporate firewall is configured to permit.

But even this has a tell, and it is a behavioural one, consistent with everything above. A server — a database host, a web backend, a router — has no business reason to talk to a consumer chat API. The anomaly is not the destination; the destination is legitimate. The anomaly is who is making the call. An outbound connection to api.telegram.org from a machine that has never had a human read a message on it is as diagnostic as a whoami that opens a session. The transport is trusted. The caller is not. Egress control and destination allowlisting — knowing which of your servers are allowed to reach the outside world, and to where — matter more here than any payload signature ever could.

The straight-for-the-hashes minority

Not everything in the record is automated enrolment. A distinct, sparser pattern goes immediately for secrets: sessions that run whoami; id; cat /etc/shadow — orientation, and then an instant attempt to read the file where password hashes live. Where the botnet operators fingerprint and enrol at machine pace, this reads as something more deliberate — credential theft, or a hands-on operator with a specific interest.

Its rarity is the finding. The overwhelming majority of post-login activity is machine-paced, playbook-driven enrolment: the same script, the same commands, the same modzmodz. The thin minority that reaches straight for /etc/shadow is a different tier of threat wearing the same front door. For a defender triaging alerts, that distinction is operational. A session that fingerprints the device and adds a sudo user is a botnet doing what botnets do — serious, but understood. A session that lands and immediately tries to read the shadow file is the tail worth escalating to a human now, because its intent is narrower and its patience suggests a person on the keyboard rather than a cron job.

What the first move teaches

Step back from the five phases and a single shape emerges. The attacker's tooling — the subject of the rest of this series — is diverse, disposable, and constantly changing. But the attacker's behaviour in the first minute is astonishingly uniform, and it is uniform because it is dictated by the situation rather than chosen by the operator. Every intruder arrives blind and must orient. The careful ones must check for sensors. The methodical ones must fingerprint before they commit. The persistent ones must plant something that survives, and reach out to fetch it. None of these are stylistic choices; they are the load-bearing structure of an intrusion, and structure is detectable in a way that style is not.

That is the defensive core of this dossier. You will lose the arms race on signatures — the payloads recompile, the C2 domains rotate, the tools are all dual-use and legitimate (Part A's entire thesis). But you can win on behaviour, because the behaviour cannot rotate away. The first move is involuntary.

Concretely, the honeypot's post-login record hands defenders a short list of high-precision, low-volume signals, each anchored to a phase:

• Orientation — a session whose opening command is whoami, id, hostname, or uname, especially on service accounts and machines where interactive login is rare. The highest-precision single signal in the set.
• Counter-surveillance — any process, on a real host, that greps passwd for phil, scans for honeypot process names, or stats core binaries for emulation. Exactly one thing means this; nothing legitimate does.
• Fingerprinting — reads of /etc/openwrt_release, RouterOS resource prints, AllowTcpForwarding / PermitTunnel checks, writable-path enumeration. The last quiet interval before a payload.
• Persistence — an unexpected addition to the sudo group, a new fixed-name account (admin1, user1), a credential change immediately after login, or the shared marker modzmodz. The clearest post-breach signals, and the marker links incidents into a campaign.
• Command-and-control — outbound connections to api.telegram.org (and consumer-messaging peers) from a server with no human and no business reason to talk to them.

None of these require you to know the attacker's name, their country, or their tool. They require you to know your own machines well enough to notice when one of them, having just accepted a login, begins by asking who it is.

Indicators (TLP:WHITE)

Cross-references

• TI-2026-075A — The Armory: What 12,000 Attackers Carry — the tooling census this behavioural study sits beneath.
• TI-2026-075B — The Cloud Contractor — AS396982, the shared cloud substrate; the payload host 35.237.91.38 closes the loop.
• TI-2026-073E — The Original Sin — the same thesis in the AI layer: trust is the attack surface. Here it is the trust placed in a messaging API; there, in an instruction stream.

This dossier documents observed adversary behaviour for defensive purposes. All indicators are published to help defenders detect intrusions on their own infrastructure. TLP:WHITE.