They logged in to a fake FortiGate and sent a Linux profiling script anyway. Seventeen sessions. Eight sources. Unchanged every time.
Four and a half days as a fake FortiGate. What automated sessions submitted after a login was accepted, what the scripts queried, and four detections worth building on your own edge.
- Observed: 89 accepted SSH logins; 44 went on to submit commands. Measured from connection open, 43 did so within a minute and 30 within two seconds.
- Repeated: the same compound Linux profiling payload, identical fragment for fragment, from eight addresses across three days; the same two-fragment compatibility sequence from eight more. Two parsed command sequences explain 33 of the 44 sessions.
- Queried: CPU count, architecture, NVIDIA GPU presence, uptime, previous logins, and shell behavior. Three distinct command sequences, 21 sessions from 11 addresses, checked for a GPU.
- Outcome: no response confirmed execution. The decoy answered with mostly FortiOS-style rejections, and the same fragment sequence recurred unchanged in later sessions. Nothing here is SonicWall telemetry or evidence of the Part 1 CVEs.
Part 1 covered two actively exploited SonicWall SMA1000 flaws. Part 2 asks a separate operational question: what does generic automation do after an edge login succeeds? In August, a Deception Check decoy presented as a FortiGate edge appliance, with an SSL-VPN login page and an SSH service, captured one answer. Different product and dataset, same defensive moment: immediately after the door opens.
The signal sharpens after login
Exposed services receive constant password guessing. The decoy's configured policy admitted 89 of 17,242 SSH guesses. Of those, 44 sessions submitted commands, and two repeated sequences explained 33. The 0.52% admission rate describes the collection funnel, not credential success against a real host; the useful signal is what followed.
- SSH password guessesStarting pool, from 635 addresses17,242
- Decoy-policy admissions0.52% of guesses89
- Sessions that submitted commands49.4% of admissions44
- Sessions explained by two repeated sequences75% of command sessions33
Each percentage compares with the step above. This sequence covers SSH only. The 25,374 VPN credential posts were a separate lane, with no address or session in both.
Those command sessions came from 24 addresses. Measured from connection open, the median gap to the first command was 1.5 seconds, and 43 of 44 arrived within a minute; that pacing is consistent with automation. Only seven distinct command sequences appeared. The dominant sequence arrived as one compound command that the decoy parsed into 90 fragments.
What the bots asked
The dominant sequence profiles a Linux host before attempting a shell self-test. Read in order, the questions are:
/proc.last.Together, those questions form a generic host profile: OS, architecture, core count, GPU presence, uptime, login history, and shell behavior. The notable mismatch is that the same Linux-oriented sequence reached a FortiGate persona.
Replay: one sequence, seen seventeen times
The payload arrived as one non-interactive SSH command. The decoy split it into 90 fragments; 89 received explicit FortiOS-style rejections, and one received an ambiguous reply. The condensed reconstruction starts when it enters view.
Written for Linux, the sequence includes fallback chains and case branches for different shells and architectures. Because it arrived as a single command, it could not adjust to the replies. The same normalized 90-fragment sequence recurred unchanged across 17 sessions from eight addresses on more than one hosting network across three days; two addresses appeared on multiple days. The recurrence and timing are consistent with automation.
Three sequences checked for GPUs
Every session that sent the dominant payload queried PCI devices for an NVIDIA adapter, right after counting cores.
Sessions that checked for a GPU, from 11 addresses. One seven-fragment sequence from a single address did little else: uptime, VGA and 3D controllers, and nvidia-smi for a product name.
GPU checks appeared in three host-profiling sequences. The decoy presented as an edge appliance, yet 21 of 44 command sessions, from 11 addresses, queried NVIDIA hardware or tooling. Those commands inventory compute capability; the capture does not show what a positive result would trigger. The credential lists add a separate signal.
AI and crypto names appeared in the guess lists
Across 635 addresses and 1,377 usernames, established guesses remained common. The lists also included names associated with AI assistants, agent tools, crypto wallets, and trading. Fourteen different addresses tried to log in to an edge appliance as claude. The bars show how many distinct addresses tried each name.
The classics
AI and crypto names
Seven addresses reused an identical 255-name list, and an eighth submitted a 254-name near-match. The list included both clawdbot and openclaw, names from the same project's evolution, alongside claude, cursor, and grok. That points to a shared, contemporary credential wordlist, not AI-tool targeting or actor attribution.
The one loader brought its own key
Three sessions from a single address were different. Instead of profiling the host, they submitted a delivery sequence, and the delivery method is the useful part.
/tmp, /var/tmp, and /dev/shm in turn.StrictHostKeyChecking no.wget or curl piped to sh.ssh argument, then delete the key, the config, and the payload.HTTP-only egress monitoring would miss the loader's first-choice scp path. Outbound SSH from an edge appliance should trigger review unless it is explicitly authorized. In these three sessions, no reply confirmed a successful step.
Scanner is a behavior, not an alibi
A targeted review on September 2 identified at least six of the 24 command-source addresses as carrying Shodan's scanner tag, which Shodan derives from scanning observed across several honeypot sensors. The tag describes observed behavior, not ownership or motive. Removing the 11 sessions tied to those six addresses left 33 command sessions; 23 still matched the two repeated sequences, about 70%. The loader's source had no scanner tag in the same review.
ATT&CK, by session
Mapped from what sessions submitted or attempted, counted by session rather than by line. These are attempts received by a decoy, not confirmed outcomes.
| Technique | What it looked like | Scope |
|---|---|---|
| T1110.001 Password Guessing | 17,242 SSH password attempts from 635 addresses | Access stage |
| T1133 External Remote Services | 89 internet-originated SSH sessions accepted by decoy policy | Access stage |
| T1059.004 Unix Shell | Shell and BusyBox commands submitted after login | 44 sessions |
| T1082 System Information Discovery | Kernel, OS, CPU, and architecture enumeration; GPU enumeration in 21 of these sessions | 44 sessions |
| T1124 System Time Discovery | Reading /proc/uptime or running uptime -p | 18 sessions |
| T1033 System Owner/User Discovery | Login history via last | 17 sessions |
| T1222.002 Linux Permissions Modification | chmod +x on a test file (17 sessions) or a payload it attempted to retrieve (3 sessions) | 20 sessions |
| T1070.004 File Deletion | Attempted deletion of the embedded key, SSH config, and retrieved payload | 3 loader sessions |
| T1105 Ingress Tool Transfer | Attempted scp with an embedded key, with wget or curl fallback | 3 sessions |
| T1016 System Network Configuration Discovery | ifconfig | 2 sessions |
| T1057 Process Discovery | ps and ps -ef queries filtered for miner process names | 2 sessions |
| T1083 File and Directory Discovery | An ls -la query across Telegram Desktop, modem, and SMS-related paths | 2 sessions |
Seventeen profiling sessions also submitted rm for a temporary self-test file. Because that deletion was part of a capability check and never executed, it is treated as lower-confidence cleanup behavior and excluded from the T1070.004 count.
What the decoy said back
Every reply in this dataset is synthetic, which keeps the findings scoped to observed attempts. Of the 1,652 fragments submitted, 1,632 (98.8%) received an explicit FortiOS-style error, and 20 received an ambiguous reply. No reply confirmed a download, execution, or permission change. The decoy preserved the command sequences and returned explicit negative replies to 98.8% of the fragments, turning accepted logins into behavioral evidence without executing the payload.
A login is a counter. What the session does next is evidence.
Four detections, plus two structural controls
These signals require different telemetry. Outbound SSH can surface at the network boundary. The command clusters apply to Linux edge and management hosts that record shell or process execution. On a FortiGate, prioritize unexpected administrator authentication and subsequent FortiOS CLI activity; optional CLI audit logging can record administrative commands. On a decoy with no legitimate users, any accepted login deserves review.
Detection you can build this week
- Outbound SSH or scp initiated by an edge appliance. HTTP-only egress monitoring would miss the loader's first-choice
scppath. Alert on outbound SSH unless it is explicitly authorized. - Linux host profiling after login. On Linux edge or management hosts with command telemetry, a cluster of
uname,nproc,lscpu,/proc/cpuinfo, andlastin the first minute can indicate automated host profiling. Baseline approved administration, and alert on the sequence. - Unexpected hardware enumeration. On Linux edge or management hosts, a burst of
lspciandnvidia-smiwarrants investigation. Three distinct sequences, covering 21 sessions from 11 addresses, submitted those checks here. - Time from connection to first command. Measured from connection open, the median here was 1.5 seconds, and 43 of 44 command sessions submitted a command within one minute. After excluding approved administrative automation, health checks, and backup or configuration jobs, short arrival times paired with repeated command sequences can indicate automation.
Structural
- Keep management interfaces off the internet, require MFA, and give appliance service accounts the minimum they need. Part 1 has the SMA1000-specific version of this list.
- Treat any accepted login on a device with no legitimate interactive users as an incident, because in this window 44 of 89 accepted logins submitted commands, and the median wait from connection open was 1.5 seconds.
Bottom line
Patching closes the door you know about. In this window, this is what came through an open one: automation that profiles the host, tests the shell, and attempts to retrieve a payload over whichever channel works. It arrived as a single command, it was resubmitted unchanged on later days, and nothing in it accounted for what it landed on. You can watch for the pattern on your real devices, and you can put something on the inside that exists only to be found by it.
Method and limits
One production Deception Check decoy emulating a FortiGate, with an SSL-VPN login page and an SSH service, observed traffic from 06:11 UTC on August 15 to 18:18 UTC on August 19, 2026, about four and a half days. The hash-pinned archive holds 53,509 sessions and 135,849 events with zero parse or integrity errors. Before analysis, we removed our own fleet addresses and sources matching a pinned catalog of 20,368 disclosed research-scanner ranges, accounting for 288 sessions.
The HTTP and SSH lanes share the deployment and observation window, but no address or session appeared in both. Counts are by session and address. The decoy splits compound shell input on &&, ||, and ;, including inside quoted strings, before logging. The profiling sequence therefore appears as 90 log rows per session. Six rows in the loader sessions are decoy-generated annotations, not submitted input. Per-fragment timing reflects decoy reply latency, not sender pacing; replies were generated live in one session and served from cache in the other sixteen.
The methodology note, addendum, reproduction script, and output hashes are held internally and available on request. Addresses, credentials, destinations, key material, and payload names are not published. Nothing in this dataset touches SonicWall, SMA1000, or either CVE from Part 1.
References
- Part 1: SonicWall SMA1000 is being exploited again, Deception Check, September 3, 2026.
- MITRE ATT&CK, technique pages linked in the table above.
- Shodan, Internet Scanners dataset: how the scanner tag is derived.