The Evasion Stack

Overview

Three distinct evasion techniques were observed across this investigation. They operate at different layers — DNS infrastructure, SSH protocol identity, and behavioral detection scope — and were not applied uniformly across all observed nodes. One technique (PTR evasion) is a pre-positioned infrastructure decision made before any specific campaign. One (banner spoofing) is a per-session identity assertion applied at the SSH library layer. One (multi-protocol scanning) is not evasion in the traditional sense but has the effect of making single-vector defenses incomplete. Together they indicate an operator with working knowledge of how security tooling identifies and classifies scanners.

┌──────────────────────────────────────────────────────────────────┐
│  LAYER 3 — DNS Infrastructure (PTR Evasion)                      │
│  Sophistication: HIGH                                            │
│  Applied to: 89.248.168.227 + 22 other IPs in 89.248.168.0/24  │
│  Technique: PTR record returns "no-reverse-dns-configured.com"   │
│  Effect: Security tools dismiss IP as having no PTR record       │
│  Pre-positioned: YES — registered 2024-05-07, renewed 2026-06-18│
├──────────────────────────────────────────────────────────────────┤
│  LAYER 2 — SSH Protocol Identity (Banner Spoofing)               │
│  Sophistication: MEDIUM                                          │
│  Applied to: 77.246.159.182 (RU node, AS29182)                  │
│  Technique: Go SSH client declares SSH-2.0-OpenSSH_7.4           │
│  Effect: Banner-matching blocklists and IDS signatures miss node │
│  Pre-positioned: PARTIAL — code modification required            │
├──────────────────────────────────────────────────────────────────┤
│  LAYER 1 — Behavioral Scope (Multi-Protocol Scanning)            │
│  Sophistication: LOW-MEDIUM                                      │
│  Applied to: 89.248.168.227 (NL node, AS202425)                 │
│  Technique: Concurrent SSH bruteforce + HTTP scanning            │
│  Effect: Single-vector monitoring misses the full activity scope │
│  Pre-positioned: NO — consequence of tool design, not evasion    │
└──────────────────────────────────────────────────────────────────┘

Layer 3 — PTR Evasion: The no-reverse-dns-configured.com Technique

How PTR Records Function in Security Tooling

When a host connects to a network resource, the receiving party can perform a reverse DNS lookup — querying the PTR record for the source IP. The result is a human-readable hostname, or the absence of one. Security tooling uses PTR results in multiple ways: reputation lookups and DNSBL scoring, SIEM correlation rule matching, firewall policy enforcement, automated abuse contact routing, and analyst triage prioritization.

When a PTR lookup returns NXDOMAIN, tools record "no reverse DNS" or a similar phrase. This is the critical observation: the string "no reverse DNS configured" does not require an absent PTR record. It only requires that the PTR record returns a string that reads as one.

Standard case — no PTR record configured:
  $ dig -x 89.248.168.X
  ;; NXDOMAIN (no PTR record exists)
  → SIEM field: PTR = "(none)" or "no reverse DNS"
  → Analyst reads: unconfigured IP, possibly ephemeral, low priority

Engineered evasion — no-reverse-dns-configured.com deployed:
  $ dig -x 89.248.168.227
  89.248.168.227.in-addr.arpa. 300 IN PTR no-reverse-dns-configured.com.
  → SIEM field: PTR = "no-reverse-dns-configured.com"
  → Analyst reads: "no reverse DNS configured" → SAME reaction

Why it works:
  (1) The string is visually and grammatically identical to a system message
  (2) SIEM rules keyed on "no-reverse-dns" fire on BOTH the real absence
      AND this domain — generating noise that trains analysts to ignore
  (3) Human triage: analyst sees "unconfigured" → deprioritizes IP
  (4) Abuse pipelines: query domain registrant (Namecheap) instead of
      AS202425 abuse contact → misdirected report, no action taken

What it does NOT do:
  × Does not block the PTR lookup (response is returned promptly)
  × Does not make the IP invisible
  → It makes the IP DISMISSIBLE, not undetectable

Registration and Active Management

Domain registrations expire annually. Renewal requires deliberate action and payment. The 2026-06-18 renewal date confirms the operator actively maintained this asset 23 days before this investigation. The "counter-narrative" that this is a provider misconfiguration or a joke domain is refuted: PTR records in AS202425 address space are not set by default provider action. Namecheap registration with active renewal and systematic deployment across 23 IPs represents deliberate operational infrastructure.

The /24 Segmentation: Three Distinct Operational Postures

89.248.168.0/24  (AS202425, IP Volume inc — bulletproof hosting)
│
├── 142 IPs  [security.criminalip.com + scanner.openportstats.com]
│   └── TRANSPARENT LAYER
│       Declared scanner identity; publicly documented
│       Benefit: commercial whitelist coverage; analyst skip via policy
│
└──  23 IPs  [no-reverse-dns-configured.com]  ← THIS INVESTIGATION
    └── DECEPTIVE LAYER
        Engineered absent-PTR appearance
        Benefit: dismissed as unconfigured, not categorized as scanner
        Evasion domain: Namecheap | registered 2024-05-07 | renewed 2026-06-18

The 142 transparent nodes operate VISIBLY (whitelisted or categorized).
The 23 deceptive nodes operate DISMISSED (neither whitelisted nor categorized).

Whether the deceptive-PTR nodes belong to the same operator as
the transparent nodes, or represent a separate tenant in AS202425
bulletproof hosting, cannot be determined from current evidence.

Security Controls Bypassed

Confidence: HIGH — Domain registered, renewed, and systematically deployed. The technique is consistent across 23 IPs. No plausible benign interpretation is consistent with the full evidence set (registration + renewal + systematic deployment).

Layer 2 — SSH Banner Spoofing: Impersonating OpenSSH 7.4

The Two Layers of SSH Identity

When an SSH client connects to a server, identity is presented at two distinct protocol layers that operate entirely independently. Understanding why banner spoofing works — and why it fails against HASSH analysis — requires examining both layers.

┌─────────────────────────────────────────────────────────────────┐
│  LAYER 1 — Version String (Banner)                              │
│  ─────────────────────────────────                              │
│  Source: OPERATOR sets this string (runtime configuration)      │
│  Content: SSH-2.0-[softwareversion]                             │
│  Example: SSH-2.0-OpenSSH_7.4                                  │
│  Logged by: Cowrie, IDS, SIEM, all SSH servers                 │
│  Verifiable? NO — no cryptographic commitment                   │
│  Can be spoofed? YES — trivial string substitution in code      │
├─────────────────────────────────────────────────────────────────┤
│  LAYER 2 — HASSH (Capability Negotiation Fingerprint)           │
│  ─────────────────────────────────────────────────────         │
│  Source: SSH LIBRARY (compiled-in algorithm defaults)           │
│  Content: MD5 of SSH_MSG_KEXINIT algorithm preference lists     │
│  Example: c39f4cec145ee3d50fb590595143b9d5                     │
│  Logged by: Honeypots with HASSH collection enabled            │
│  Verifiable? YES — derived from actual handshake bytes          │
│  Can be spoofed? NOT by banner change alone                    │
└─────────────────────────────────────────────────────────────────┘

77.246.159.182 modified Layer 1:  banner → SSH-2.0-OpenSSH_7.4
Layer 2 (HASSH) remained:         c39f4cec... (Go SSH library)

The contradiction between the two layers IS the forensic evidence.
The banner string and the HASSH are produced by separate code paths.
Changing one does not affect the other.

The Evidence

The HASSH is derived from bytes transmitted during the handshake. It is not possible to produce a Go HASSH while running a native OpenSSH binary. It is not possible to produce an OpenSSH HASSH while running the Go SSH library that generated this fingerprint — without modifying the actual capability negotiation code, which would produce a different HASSH. The banner string is the lie; the HASSH is the evidence.

Why OpenSSH 7.4 Was Chosen

OpenSSH 7.4 (December 2016) was the default on CentOS 7 — one of the most widely deployed server platforms of its era. It represents a version that is plausible for a long-running unpatched host, is not so old as to be immediately suspicious, and critically, is not one of the known scanner banner strings that blocklists and IDS signatures target: SSH-2.0-Go, SSH-2.0-libssh2_*, SSH-2.0-python-paramiko_*. By presenting as SSH-2.0-OpenSSH_7.4, the client avoids scanner-specific banner blocklists while reading as a legitimate (if outdated) host.

Detection Gap

Any detection rule, blocklist, or investigation workflow that stops at the SSH version banner will miss 77.246.159.182 — or classify it as a potentially legitimate outdated SSH server rather than a scanning node. The HASSH c39f4cec145ee3d50fb590595143b9d5 is a watch indicator: any new session presenting this fingerprint, regardless of banner, source IP, or ASN, should be correlated to TI-2026-057.

Confidence: HIGH — The HASSH contradiction is a direct measurement of transmitted handshake bytes, not an inference from secondary signals.

Layer 1 — Multi-Protocol Dual-Vector Scanning

The Observed State

At the time of observation (2026-06-30), 89.248.168.227 held two active CrowdSec bans from two independent detection scenarios, running concurrently:

Observation timestamp: 2026-06-30

SSH ban (cowrie-ssh-bruteforce) — 23 hours remaining:
  23h before 2026-06-30 = SSH bruteforce activity ~2026-06-29

HTTP ban (http:scan) — 164 hours remaining:
  164h ÷ 24 = 6.83 days = HTTP scanning activity ~2026-06-23

Reconstructed timeline:
  ─────────────────────────────────────────────────────────────────
  2026-06-23  ──  HTTP reconnaissance campaign begins
                  [web scanning activity triggers CrowdSec http:scan]
       │
       │  ██████████████████████ 7 days of HTTP scanning ████████
       │
  2026-06-29  ──  SSH bruteforce campaign begins
                  [cowrie-ssh-bruteforce triggered; MikroTik notified]
       │
  2026-06-30  ──  Cowrie honeypot interaction recorded
                  MikroTik address-list block applied
                  Investigation triggered — BOTH bans active simultaneously
  ─────────────────────────────────────────────────────────────────

Sequence interpretation:
  Phase 1: Broad web reconnaissance (target identification / enumeration)
  Phase 2: Targeted SSH credential attacks (access attempt on identified targets)

  The MikroTik block was triggered by SSH activity.
  The HTTP campaign that preceded it by one week was invisible
  to SSH-only detection pipelines until enrichment surfaced it.

What This Rules Out

A commodity SSH bruteforcer — Hydra, Medusa, a basic Python script with Paramiko — does not produce an http:scan CrowdSec ban as a side effect of SSH activity. The HTTP ban requires HTTP-specific scanning behavior that triggered CrowdSec's web-scanning detection scenarios. This means 89.248.168.227 was running at minimum two distinct scanning workloads simultaneously. Whether these are separate tools running in parallel or a single multi-protocol reconnaissance platform is not determined from current evidence. What is established: this node is not a single-purpose SSH tool. It is a general-purpose scanning platform conducting simultaneous multi-vector reconnaissance.

Detection Gap

The MikroTik block was triggered by cowrie-ssh-bruteforce. A defender operating with SSH-only honeypot coverage and no web-scanning detection would have the HTTP campaign completely invisible — the web-facing attack surface was subject to active scanning for approximately a week before the IP appeared in SSH-related alerts. The http:scan ban duration (164h vs the SSH ban's 23h) suggests the HTTP campaign was substantially longer than the SSH campaign. Multi-protocol posture means single-vector monitoring produces a systematically incomplete picture of this node's activity.

Confidence: HIGH — Two concurrent CrowdSec bans are direct operational telemetry from two independent detection scenarios. The timeline reconstruction uses ban duration arithmetic from observed timestamps.

Sophistication Assessment

Technique Ranking

Combined Operator Profile

PTR EVASION — required capabilities:
  • Domain registration with deliberate name selection
    The string must read as a system message to analysts scanning logs
  • DNS deployment coordinated across 23 IPs within AS202425
  • Active maintenance: renewal 23 days before observation
  • Knowledge of how PTR values are processed by:
      — SIEM string-match rules (literal string match on PTR fields)
      — Automated abuse contact lookup systems
      — Human analyst triage workflows (cognitive pattern recognition)
      — Reputation scoring systems that differentiate PTR vs no-PTR

BANNER SPOOFING — required capabilities:
  • Knowledge that SSH scanner banners are targeted by blocklists/IDS
  • Modification of Go SSH client to substitute identification string
  • Selection of a plausible but non-suspicious legacy version string
  • Understanding of which banner strings attract scanner classification

MULTI-PROTOCOL SCANNING — required capabilities:
  • Platform capable of simultaneous SSH and HTTP reconnaissance
  • Deployment and coordination of multiple scanning workloads on one node

──────────────────────────────────────────────────────────────────
AGGREGATE ASSESSMENT:

An opportunistic credential stuffer deploying commodity tools
does NOT exhibit this pattern.

The PTR technique alone required 2+ years of infrastructure
maintenance (registered 2024, renewed 2026 — active at observation).

The banner spoofing required tool modification informed by knowledge
of defender blocklist behavior.

The multi-protocol scanning indicates general-purpose reconnaissance
capability, not a single-function SSH brute-force script.

This is deliberate, layered, maintained evasion infrastructure.

What the Aggregate Profile Resembles

This profile is consistent with organized scanning infrastructure operated for sustained reconnaissance — either self-directed (building target lists for later exploitation) or commercial (scanning-as-a-service sold to third parties). Supporting indicators:

• Bulletproof hosting choice (AS202425, IP Volume inc) — hosting designed to resist takedown requests
• Evasion domain registered 2024, renewed on schedule in 2026 — minimum 2 years of deliberate operational investment
• Multi-protocol tooling indicating capability extending beyond a single credential-stuffing script
• Unclassified private HASSH (only 2 IPs) indicating purpose-built tooling, not commodity deployment
• The Moscow node (AS29182 JSC IOT) choosing banner spoofing but no PTR evasion, while the NL node takes the opposite configuration — suggesting either different operator configurations or different targeting priorities

Known Unknowns

Summary

All claims in this article are derived directly from evidence items E2, E3, E4, and E7. No claim is made beyond what the cited evidence directly supports. Confidence assessments reflect the quality of the underlying evidence, not the severity of the conclusion.