A commodity SSH botnet, an institutional relay, and 23 seconds of forensic evidence.

Observation window: 2026-05-11 → 2026-05-18 (7.5 days)

Primary signal: SSH brute-force and post-exploitation activity from 185.216.134.126 (AS29256, Syrian Telecommunication - NANS allocation), relaying activity consistent with Outlaw/mdrfckr botnet propagation: authorized_keys persistence and host reconnaissance for cryptomining.

Actor confidence: behaviorally consistent with Outlaw/SHELLBOT/mdrfckr (Elastic Security Labs, Kaspersky Apr 2025, Trend Micro 2019). The mdrfckr SSH key fingerprint, the warnight/warnightkardesim wordlist markers, and the reconnaissance command sequence are established Outlaw signatures. We assess this as compromised institutional infrastructure serving as a botnet relay, not as evidence of state-directed activity.

New contribution: (a) to our knowledge, the first public documentation of Outlaw/mdrfckr activity relayed through this Syrian government-attributed IP space (AS29256); (b) a three-tier SSH scanning pipeline with graduated libssh versions, the exploitation component advertising ML-KEM-capable key exchange; (c) specific IOCs from this Syrian government-attributed IP space not previously reported.

Defensive value: medium-high. The Outlaw detection signatures are well-established; the new contribution is infrastructure attribution and the modern SSH stack observation on the exploitation component.


Attribution boundary

This report documents malicious SSH activity originating from IP space publicly attributed to Syrian institutional infrastructure. We assess the most likely scenario as compromise and botnet relay use of an under-monitored host.

We do not assess this activity as state-directed. We do not attribute operator identity. We do not infer that NANS, STE, or any Syrian public authority intentionally operated the botnet.


Executive finding

A host in IP space attributed to Syrian government services (AS29256) is relaying activity consistent with the Outlaw/mdrfckr botnet - a financially motivated SSH worm active since at least 2018. The host performs credential spraying against exposed SSH targets observed by our sensors, and when a weak password succeeds, it deploys the botnet’s signature mdrfckr SSH key for persistent access and enumerates the compromised machine for cryptomining suitability.

The botnet itself is not new. Elastic Security Labs calls it “persistent, unsophisticated, and surprisingly effective.” Kaspersky documented a resurgence in March 2025 after a three-month dormancy. What appears less documented is the infrastructure currently relaying it: a network allocation attributed to a government authority responsible for Syria’s national IT services.

We have also observed a sibling IP (91.144.21.210) on the STE backbone performing pure port discovery against a separate sensor deployment, suggesting a graduated scanning pipeline using multiple IPs within Syrian state telecom-attributed infrastructure.


The relay: IP space attributed to Syrian government services

The observed IP 185.216.134.126 sits inside infrastructure publicly attributed to:

FieldValue
ASNAS29256
OrganizationSyrian Telecommunication Establishment (STE)
Network block185.216.132.0/22
AttributionNANS - National Authority for Information Technology Services
CountrySyria
VirusTotalAs of 2026-05-20, flagged as malicious by 16/92 engines; reputation score -4

NANS (الهيئة الوطنية لخدمات تقانة المعلومات) is publicly described as Syria’s government IT authority, responsible for network services across state institutions. The 185.216.132.0/22 block is part of the STE backbone attributed to government services.

This does not appear to be ordinary residential broadband space. Public routing and allocation data place the observed IP inside infrastructure attributed to Syrian institutional or government IT services.

Historical context

Syrian government networks have a documented history of security weaknesses. In 2015, the “Cyber Justice Team” claimed a breach of nans.gov.sy, leaking data from 55 Syrian government domains - much of it attributed to default CMS installations and poor maintenance (SecurityAffairs). A decade of conflict, sanctions, and infrastructure degradation has compounded these vulnerabilities. Access Now’s 2026 reporting on Syria’s digital infrastructure highlights the ongoing decay.

Years of conflict, sanctions, and institutional degradation make under-monitored public-sector or telecom infrastructure plausible without implying state direction.

The most likely explanation is ordinary compromise of an under-monitored host.


Why this matters

Old commodity botnets continue to win because institutional infrastructure remains poorly maintained. When a host in government-attributed IP space becomes a botnet relay:

  • The relay IP may benefit from institutional network reputation and may not be treated like disposable VPS or residential botnet space.
  • The institution’s own network may face deeper compromise beyond what our SSH-focused sensors can see.
  • Defenders who focus only on sophisticated malware miss the volume threat: simple SSH brute-force with mdrfckr-style persistence has been active since 2018 and still finds weak passwords.

This report documents one such case end-to-end.


What we captured: three tools, one pipeline

Our sensors recorded 558 SSH telemetry events from 185.216.134.126 across 7.5 days, collapsing into 114 SSH sessions: 31 from the exploitation client (all on a single edge, May 11), 83 from the brute-force scanner (across 5 edges, May 15-18). The exploitation client also performs credential testing: 30 of its 31 sessions failed authentication; the 31st succeeded and triggered the post-auth burst documented below. An event is a single honeypot log record; a session is one SSH connection. Multiple event types fire per session (key exchange, authentication, fingerprint, summary), which explains why 558 events yield 114 sessions.

The same IP runs two distinct SSH clients depending on phase: the brute-force scanner (libssh 0.9.6) and the exploitation client (libssh 0.12.0). A sibling IP adds a third tool for port discovery. The combined pattern is consistent with Outlaw’s known multi-stage architecture, but with an unexpected upgrade on the exploitation side.

Tool 1: Port discovery (libssh 0.7.4)

A sibling IP on the STE backbone, 91.144.21.210, runs a minimal SSH client:

  • Banner: SSH-2.0-libssh_0.7.4
  • HASSH: e37f354a101aff58...
  • Behavior: connect → key exchange → disconnect. No authentication attempted.
  • Volume: 38,000+ events across 4 days on a separate sensor deployment
  • Algorithm set: minimal (4 kex algorithms, legacy ciphers including DH group1-sha1)

This is the reconnaissance tier - port scanning to identify live SSH services.

Tool 2: Credential brute-force (libssh 0.9.6)

The same IP, in scanner mode, uses a standard libssh client:

  • Banner: SSH-2.0-libssh_0.9.6
  • HASSH: f555226df1963d1d...
  • Behavior: one username:password pair per connection, rotate edges daily
  • Volume: 83 sessions across 5 edges over 4 days
  • Algorithm set: full libssh 0.9.6 suite including legacy 3des-cbc and hmac-sha1
  • Wordlist markers: warnight, warnightkardesim (established Outlaw dictionary signatures)
  • Notable passwords: P@ssw0rd@2025, !QAZ2wsx2025, ubuntu@2026 - year-tagged, recently updated

This is the brute-force tier - spraying weak credentials across the sensor network. The scanner rotated across sensors during active days rather than scanning the full network continuously.

Tool 3: Post-exploitation payload (libssh 0.12.0 - ML-KEM-capable negotiation)

In exploitation mode, the same IP connects with a different SSH client to deliver the payload:

  • Banner: SSH-2.0-libssh_0.12.0
  • HASSH: af8223ac9914f509...
  • Key exchange: ML-KEM-768 (post-quantum), sntrup761, curve25519 - plus strict-kex negotiation
  • Host key types: includes FIDO2 (sk-ssh-ed25519, sk-ecdsa)
  • Ciphers: chacha20-poly1305, AES-GCM only - no legacy CBC or 3DES
  • Compression: zlib@openssh.com available

This exploitation client is significantly more modern than the scanner. The client advertises ML-KEM-capable key exchange (Module-Lattice Key Encapsulation Mechanism, NIST FIPS 203). We do not infer strategic post-quantum intent; the simpler explanation is that the exploitation component was rebuilt against a modern SSH/libssh stack that exposes ML-KEM-capable negotiation by default.

The scanner stays on legacy libssh 0.9.6 (compatibility with old targets), while the exploitation tool inherits the capabilities of a recent library rebuild. A pragmatic engineering choice.


23 seconds of Outlaw: the full command transcript

On May 11 at 02:32 UTC, the exploitation tool authenticated as ubuntu with a weak password on one of our honeypot edges. What followed was a 23-second burst of 18 commands, with one SSH channel opened per command - the complete Outlaw post-exploitation playbook:

Phase 1 - Persistence (T+0s)

cd ~; chattr -ia .ssh; lockr -ia .ssh

Remove immutable and append-only attributes from .ssh directory. The lockr command is an Outlaw-specific variant (possibly a renamed binary or alias).

cd ~ && rm -rf .ssh && mkdir .ssh && \
  echo "ssh-rsa AAAAB3NzaC1yc2EAAAAB[…]oRw== mdrfckr" \
  >> .ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~

The signature move: destroy the existing .ssh directory, create a fresh one, inject the RSA public key with the comment mdrfckr. This key has been documented by Elastic Security Labs, Kaspersky, Trend Micro, SektorCERT, and others as the persistent Outlaw identifier since 2018.

Phase 2 - Credential change (T+8s)

echo -e "<redacted>\nvdXQZKrm3Ln0\nvdXQZKrm3Ln0" | passwd | bash
echo "<redacted>\nvdXQZKrm3Ln0\nvdXQZKrm3Ln0\n" | passwd

Two attempts to change the password (different quoting strategies). The new password vdXQZKrm3Ln0 is randomized per session - a slight improvement over older Outlaw variants that used fixed passwords.

Phase 3 - Host reconnaissance for mining suitability (T+8s to T+21s)

CommandPurpose
cat /proc/cpuinfo | grep name | wc -lCount CPU cores
cat /proc/cpuinfo | grep name | head -n 1 | awk '{print $4,$5,$6,$7,$8,$9;}'CPU model
free -m | grep Mem | awk '{print $2,$3,$4,$5,$6,$7}'Memory stats
ls -lh $(which ls)Anti-container check (busybox detection)
crontab -lCheck for competing miners
wWho is logged in (detect admins)
uname -mArchitecture
cat /proc/cpuinfo | grep model | grep name | wc -lCPU cores (redundant)
topRunning processes (competitor detection)
uname -aFull kernel info
whoamiConfirm identity
lscpu | grep ModelCPU model (third check)
df -h | head -n 2 | awk 'FNR == 2 {print $2;}'Root disk size

The triple CPU enumeration (cpuinfo × 2, lscpu × 1) is characteristic of Outlaw: the botnet’s economic model depends on mining yield, so it over-indexes on CPU assessment. The anti-container check (ls -lh $(which ls)) and competitor detection (crontab -l, top) are standard Outlaw pre-deployment steps documented by Elastic Security Labs.

All 18 commands were executed in 23 seconds with no human interaction - pure automation.


Behavioral profile

DimensionAssessment
Duration of activity7.5 days (May 11-18)
Total sessions114 (113 failed authentication, 1 successful post-auth exploitation)
Success rate0.88% (1/114)
Scanning patternNon-continuous; one edge targeted per active day
Activity timelineMay 11 (exploitation + brute-force, single sensor) → 3-day gap → May 15-18 (brute-force only, rotating across 4 additional sensors)
Usernames tried45 distinct (root, ubuntu, admin, hadoop, kafka, ansible, postgres…)
Passwords tried103 distinct (year-tagged, service defaults, regional variants)
Post-auth duration23 seconds
Commands executed18
Channels opened18 (one channel per command - Outlaw signature)
File transfers0 (payload deployment happens on return via the injected SSH key)

The activity was not continuous. We observed a first wave on May 11 (exploitation + brute-force, single edge), followed by a three-day gap, then renewed scanning from May 15 to May 18 across four additional edges. The gap is consistent with botnet C2 scheduling - the node likely received a new target list or resumed scanning after an idle period.


Broader pattern

We have observed similar relay patterns from other institutional networks during the same period, but this report only documents the Syrian IP space case.


What this report does not claim

  • We do not claim state-directed activity. The observed behavior is consistent with ordinary compromise and botnet relay.
  • We do not claim to have identified the botnet operator. The mdrfckr key and Outlaw markers are behavioral matches, not operator identification.
  • We do not claim the host at 185.216.134.126 is exclusively used for Outlaw relay. Our SSH-focused sensors see only SSH traffic.
  • We do not claim zero-day exploitation or novel sophistication. This is a commodity botnet exploiting weak SSH passwords.
  • We do not claim this is the first Outlaw instance relayed through institutional infrastructure. It is, to our knowledge, the first public documentation of such a case from this IP space.

Evidence quality

DimensionStrengthBasis
SSH behavior and command transcriptStrongFull 18-command capture with timestamps, channels, client versions
Outlaw/mdrfckr family attributionMediumBehavioral match: known SSH key, known wordlist markers, known command sequence
Network ownershipMediumPublic ASN/allocation data (RIPE, RIR records). We have not verified asset-level ownership beyond network registration
ML-KEM-capable exploitation clientStrongKEXINIT captured: mlkem768x25519-sha256 at position 0 (first_kex), verified across 760 kex_complete events from clients sharing HASSH af8223ac. Capability exposed by negotiation, not strategic intent inferred
Two-tool / three-tier pipelineMediumInferred from distinct HASSH + banner combinations from related IPs
State directionNot claimed-
Operator identityNot claimed-

IOCs

Network

IndicatorContext
185.216.134.126Outlaw exploitation node, AS29256 STE (Syria)
91.144.21.210Port discovery scanner, AS29256 STE (Syria)
AS29256Syrian Telecommunication Establishment

SSH fingerprints

HASSHClientRole
af8223ac9914f509afdadfaf5f7ee94elibssh 0.12.0 (ML-KEM-capable)Exploitation
f555226df1963d1d3c09daf865abdc9alibssh 0.9.6Brute-force
e37f354a101aff5871ba233aa82b84eclibssh 0.7.4Port discovery

Host

IndicatorContext
SSH key comment mdrfckrOutlaw persistence signature
SSH public key AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2l[…]oRw==Outlaw RSA key (2048-bit)
SSH key fingerprint SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7CwFor authorized_keys hunting
Password vdXQZKrm3Ln0Planted by this session
Wordlist marker warnight / warnightkardesimOutlaw dictionary signature

MITRE ATT&CK

TechniquePhase
T1110.001 - Brute Force: Password GuessingInitial Access
T1098.004 - SSH Authorized KeysPersistence
T1098 - Account ManipulationPersistence
T1082 - System Information DiscoveryDiscovery
T1033 - System Owner/User DiscoveryDiscovery
T1057 - Process DiscoveryDiscovery

Defensive takeaways

This is low-sophistication, high-volume SSH abuse. Detection opportunities:

  • Hunt authorized_keys: alert on entries containing the comment mdrfckr or the key fingerprint SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw.
  • HASSH blocklisting: the three HASSH fingerprints above can be used as SIEM indicators. The exploitation HASSH af8223ac is particularly high-signal in our dataset - we observed it only in automated post-auth exploitation, not in legitimate client activity.
  • Rapid post-auth burst detection: alert on SSH sessions that combine .ssh directory reset, authorized_keys rewrite, passwd attempts, and system enumeration (cpuinfo, free, uname, lscpu, df) within a 30-second window.
  • Institutional IP space monitoring: do not assume that reputable ASN context implies benign origin. Government-attributed and academic IP ranges can host compromised relay nodes.
  • Baseline SSH hygiene: disable password authentication where possible, enforce key-only or MFA access, and alert on successful logins followed by immediate .ssh directory replacement.

Prior art and references

The Outlaw botnet is extensively documented. This report extends the public record with infrastructure attribution, not with new malware analysis.

  1. Elastic Security Labs - “Outlaw Linux Malware: Persistent, Unsophisticated, and Surprisingly Effective” - https://www.elastic.co/security-labs/outlaw-linux-malware
  2. Kaspersky Securelist (Apr 2025) - “Outlaw botnet detected” - https://securelist.com/outlaw-botnet/116444/
  3. Trend Micro (2019) - “Outlaw Hacking Group’s Botnet” - https://www.trendmicro.com/en_us/research/19/f/outlaw-hacking-groups-botnet-observed-spreading-miner-perl-based-backdoor.html
  4. SektorCERT (Jun 2024) - Botnet TLP:CLEAR report (94.5% probability of mdrfckr tag in Outlaw traffic) - https://sektorcert.dk/wp-content/uploads/2024/06/Botnet-EN-TLP_CLEAR-202406.pdf
  5. Access Now (2026) - Syria sanctions and digital infrastructure - https://www.accessnow.org/syria-sanctions-digital-future/
  6. Barracuda (Q1 2026) - Middle East brute-force surge - https://www.cybersecuritydive.com/news/brute-force-cyberattacks-originating-in-middle-east-surge-in-q1/817440/

Coordination note: we attempted responsible notification through reachable abuse or network coordination channels before publication. We do not describe private correspondence or infer operator response.

Our sensors observe what lands on our honeypots. The host at 185.216.134.126 may be involved in other malicious activity that our SSH-focused infrastructure cannot see. Network defenders with visibility into this IP space should investigate SSH relay activity associated with the IOCs above.