Nation-State Tradecraft in Our Honeypot: Why Federal Buyers Should Care About Commercial Threat Intel

Between March 29 and April 5, 2026, a single IP address connected to a Cowrie SSH (Secure Shell) honeypot we operate six times across seven days and executed the same precisely sequenced attack each session. The IP resolves to AS0 "not routed" in DShield's BGP (Border Gateway Protocol) monitoring, which is the kind of routing anomaly that typically indicates hijacked address space or dedicated infrastructure that avoids public announcement. The SSH key injected by the campaign carries a comment of rsa-key-20230629, meaning the operator has been running this exact tooling for nearly three years. Zero of 76 commercial antivirus engines flag the artifact. This is not a script kiddie, and it is not commodity malware.

We are publishing the technical details because the organizations most exposed to this class of attack are the ones least likely to detect it: small defense contractors, SDVOSB (Service-Disabled Veteran-Owned Small Business) subcontractors on federal vehicles, and the commercial IT providers those subcontractors rely on. The same operational maturity we observed in our commercial honeypot is present in campaigns targeting the federal supply chain. The difference is that on a federal system handling Controlled Unclassified Information (CUI), a single undetected persistent backdoor is a reportable cyber incident For a comprehensive overview of the compliance requirements that make this detection work relevant to federal buyers, see CMMC Compliance for Small Defense Contractors: The Complete Guide. under DFARS 252.204-7012 and a Level 2 CMMC (Cybersecurity Maturity Model Certification) assessment failure.

Why Should Federal Buyers Care About a Commercial Honeypot?

Federal buyers should care because the threat infrastructure that scans commercial Linux hosts is the same infrastructure that scans federal supply chain targets. Attackers do not segregate their target selection by your Federal Supply Code. They scan the entire IPv4 space and adapt the post-exploitation payload based on what they find. A subcontractor whose IT provider runs its own threat intelligence infrastructure has observed these tactics in the wild and built specific detections for them. A subcontractor whose IT provider relies on commercial antivirus feeds has not.

Under NIST SP 800-171 Revision 2, prime contractors are responsible for the security posture of every subcontractor with CUI access. The revised rule under NIST SP 800-171 Revision 3, published in 2024, tightens this further by requiring explicit documentation of how security controls flow down through the supply chain. When a prime asks an SDVOSB subcontractor how they detect SSH key tampering on a Linux host storing CUI, "we use antivirus" is not an acceptable answer. The honeypot data from this campaign demonstrates exactly why.

How Does This Backdoor Work?

The attack chain runs in 28 seconds or less and uses standard Linux utilities exclusively. There is no novel exploit, no dropped binary, no memory corruption. The only "malware" involved is a 398-byte text file containing an OpenSSH RSA (Rivest-Shamir-Adleman) public key. VirusTotal misclassifies this key as PowerShell because antivirus engines have no meaningful way to flag a legitimate file format.

Each session executes four distinct phases. Phase one runs a cleanup script that targets competing malware and cryptocurrency miners already on the host. This anti-competition behavior is a signature of well-resourced botnet operations that protect their resource investment by evicting rival operators. Phase two runs a setup script that installs the attacker's own tooling. Both scripts self-delete immediately after execution to eliminate forensic artifacts. Phase three is the persistence injection, and it is worth reading carefully:

mkdir -p ~/.ssh
chattr -ia ~/.ssh/authorized_keys
echo "ssh-rsa AAAAB3NzaC1yc2E... rsa-key-20230629" > ~/.ssh/authorized_keys
chattr +ai ~/.ssh/authorized_keys
uname -a
echo -e "\x61\x75\x74\x68\x5F\x6F\x6B\x0A"

The chattr -ia command removes any existing immutable or append-only filesystem attributes on the authorized_keys file. This step exists because the attacker knows the file may have been locked by a previous run of this same bot or by a competing attacker using the same technique. The echo command then overwrites the file with the attacker's RSA key. Finally, chattr +ai re-locks the file with both immutable and append-only flags, which means the file cannot be modified, deleted, renamed, or hard-linked, even by root. MITRE ATT&CK classifies this as T1222.002, File and Directory Permissions Modification on Linux.

The final line is a hex-encoded success beacon. The bytes spell "auth_ok" but are encoded as hex to evade intrusion detection systems that string-match on plaintext indicators. This is a small detail that reveals a large amount about the operator's discipline.

Why Can't Antivirus Catch This?

An SSH public key is a legitimate system file format. The attacker's key is structurally identical to an authorized administrator's key. There is no malicious payload to scan for, no suspicious binary to flag, no signature to match. This is why we observed a 0 of 76 detection rate across the VirusTotal commercial engine set. VirusTotal's own classifier tagged the file as "PowerShell" with attributes long-sleeps and detect-debug-environment, which is an obvious misclassification, because standard text-based heuristics cannot reason about the context of where a key was written or with what attributes.

Detection requires behavioral monitoring of T1098.004 Account Manipulation: SSH Authorized Keys. File integrity monitoring must watch the authorized_keys file for content changes and extended attribute changes. Audit rules must capture the write and the subsequent chattr call. Configuration management tools must include lsattr checks in their compliance baselines. Almost no small defense subcontractor has this telemetry in place, because the off-the-shelf security stacks most of them deploy are optimized for detecting binary malware, not for catching legitimate utilities being used in illegitimate ways.

What Does the Infrastructure Tell Us?

The attacker IP resolves to AS0 "not routed" per DShield's BGP monitoring. This is significant. AS0 is the designation the routing registry uses when no autonomous system has announced a path to a prefix. For a live attacker IP, AS0 routing typically means one of three things: the attacker is announcing a hijacked BGP prefix for address space they do not own, they are using stale routing data that DShield's collectors have not updated, or they are making ephemeral BGP announcements that withdraw between active scanning windows. MANRS (Mutually Agreed Norms for Routing Security) documents BGP hijacking as a known technique for establishing untraceable attack infrastructure.

Combined with the three-year-old signing key, the custom Go language SSH client identified by HASSH fingerprint 5f904648ee8964bef0e8834012e26003, and the persistent single-IP behavior across multiple sessions, this profile does not match an opportunistic commodity botnet. It matches a purpose-built, dedicated scanning operation with institutional continuity. Whether that institution is criminal or state-adjacent is outside what our honeypot data can prove, but the discipline and longevity are consistent with either.

What Should Federal Subcontractors Do?

The defensive controls are well-understood and relatively cheap to implement. What blocks them is operational attention, not budget.

1. Disable root SSH login. Set PermitRootLogin no in /etc/ssh/sshd_config on every Linux system that handles CUI. Every session we observed targeted root with trivially weak passwords. This single change blocks the entire attack chain. NIST SP 800-171 control 3.1.6 (use of non-privileged accounts) explicitly requires this.
2. Disable SSH password authentication entirely. Set PasswordAuthentication no. Key-based authentication with a managed key inventory eliminates the brute-force entry vector. This is also required by DISA STIGs (Defense Information Systems Agency Security Technical Implementation Guides) for most Linux baselines.
3. Monitor authorized_keys with file integrity monitoring. Configure Wazuh, OSSEC, AIDE, or equivalent to watch ~/.ssh/authorized_keys for every user on every CUI system. Alert on content modification, creation, and attribute changes. This addresses NIST SP 800-171 control 3.3.1 (create audit records).
4. Audit extended filesystem attributes. Run lsattr as a scheduled check across all authorized_keys files. Any file with the i or a flags set is an indicator of compromise and should trigger investigation, not quiet remediation. Add this to your continuous monitoring plan under control 3.14.3.
5. Block traffic from AS0 and known anomalous ASNs at the perimeter. Unrouted traffic has no legitimate business purpose for federal contractors. Perimeter firewalls and edge routers should drop it by default. This is a supply chain risk management control under NIST SP 800-161 Revision 1 that directly supports NIST SP 800-171 control 3.13.5 (boundary protection).
6. Log SSH client fingerprints. The HASSH value in this campaign (5f904648ee8964bef0e8834012e26003) is a reliable behavioral indicator that the session is automated scanning rather than a legitimate administrator. Feed HASSH values into your SIEM (Security Information and Event Management) and alert on known-bad fingerprints.

What This Means for the Supply Chain

The federal acquisition community has been warning about supply chain risk for years, and the CMMC program exists precisely to formalize those concerns into enforceable requirements. But the requirements only matter if the subcontractor is operationally capable of implementing them. A subcontractor whose IT provider has never seen a real SSH persistence attack is not positioned to detect one on a federal system. A subcontractor whose IT provider runs threat intelligence infrastructure and publishes findings is better positioned, not because honeypots are prestigious, but because running one forces the operator to build and maintain the exact detection controls the CMMC framework requires.

This is the capability gap federal buyers should be probing when they evaluate SDVOSB subcontractors. Ask for the threat intelligence the IT provider has produced. Ask for the detection rules they have deployed in response to it. Ask to see the audit logs that demonstrate those rules are active. These are reasonable questions, and subcontractors who cannot answer them are candidates for a closer look.