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_keyspersistence and host reconnaissance for cryptomining.Actor confidence: behaviorally consistent with Outlaw/SHELLBOT/mdrfckr (Elastic Security Labs, Kaspersky Apr 2025, Trend Micro 2019). The
mdrfckrSSH key fingerprint, thewarnight/warnightkardesimwordlist 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:
| Field | Value |
|---|---|
| ASN | AS29256 |
| Organization | Syrian Telecommunication Establishment (STE) |
| Network block | 185.216.132.0/22 |
| Attribution | NANS - National Authority for Information Technology Services |
| Country | Syria |
| VirusTotal | As 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)
| Command | Purpose |
|---|---|
cat /proc/cpuinfo | grep name | wc -l | Count 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 -l | Check for competing miners |
w | Who is logged in (detect admins) |
uname -m | Architecture |
cat /proc/cpuinfo | grep model | grep name | wc -l | CPU cores (redundant) |
top | Running processes (competitor detection) |
uname -a | Full kernel info |
whoami | Confirm identity |
lscpu | grep Model | CPU 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
| Dimension | Assessment |
|---|---|
| Duration of activity | 7.5 days (May 11-18) |
| Total sessions | 114 (113 failed authentication, 1 successful post-auth exploitation) |
| Success rate | 0.88% (1/114) |
| Scanning pattern | Non-continuous; one edge targeted per active day |
| Activity timeline | May 11 (exploitation + brute-force, single sensor) → 3-day gap → May 15-18 (brute-force only, rotating across 4 additional sensors) |
| Usernames tried | 45 distinct (root, ubuntu, admin, hadoop, kafka, ansible, postgres…) |
| Passwords tried | 103 distinct (year-tagged, service defaults, regional variants) |
| Post-auth duration | 23 seconds |
| Commands executed | 18 |
| Channels opened | 18 (one channel per command - Outlaw signature) |
| File transfers | 0 (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
mdrfckrkey and Outlaw markers are behavioral matches, not operator identification. - We do not claim the host at
185.216.134.126is 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
| Dimension | Strength | Basis |
|---|---|---|
| SSH behavior and command transcript | Strong | Full 18-command capture with timestamps, channels, client versions |
| Outlaw/mdrfckr family attribution | Medium | Behavioral match: known SSH key, known wordlist markers, known command sequence |
| Network ownership | Medium | Public ASN/allocation data (RIPE, RIR records). We have not verified asset-level ownership beyond network registration |
| ML-KEM-capable exploitation client | Strong | KEXINIT 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 pipeline | Medium | Inferred from distinct HASSH + banner combinations from related IPs |
| State direction | Not claimed | - |
| Operator identity | Not claimed | - |
IOCs
Network
| Indicator | Context |
|---|---|
185.216.134.126 | Outlaw exploitation node, AS29256 STE (Syria) |
91.144.21.210 | Port discovery scanner, AS29256 STE (Syria) |
| AS29256 | Syrian Telecommunication Establishment |
SSH fingerprints
| HASSH | Client | Role |
|---|---|---|
af8223ac9914f509afdadfaf5f7ee94e | libssh 0.12.0 (ML-KEM-capable) | Exploitation |
f555226df1963d1d3c09daf865abdc9a | libssh 0.9.6 | Brute-force |
e37f354a101aff5871ba233aa82b84ec | libssh 0.7.4 | Port discovery |
Host
| Indicator | Context |
|---|---|
SSH key comment mdrfckr | Outlaw persistence signature |
SSH public key AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2l[…]oRw== | Outlaw RSA key (2048-bit) |
SSH key fingerprint SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw | For authorized_keys hunting |
Password vdXQZKrm3Ln0 | Planted by this session |
Wordlist marker warnight / warnightkardesim | Outlaw dictionary signature |
MITRE ATT&CK
| Technique | Phase |
|---|---|
| T1110.001 - Brute Force: Password Guessing | Initial Access |
| T1098.004 - SSH Authorized Keys | Persistence |
| T1098 - Account Manipulation | Persistence |
| T1082 - System Information Discovery | Discovery |
| T1033 - System Owner/User Discovery | Discovery |
| T1057 - Process Discovery | Discovery |
Defensive takeaways
This is low-sophistication, high-volume SSH abuse. Detection opportunities:
- Hunt
authorized_keys: alert on entries containing the commentmdrfckror the key fingerprintSHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw. - HASSH blocklisting: the three HASSH fingerprints above can be used as SIEM indicators. The exploitation HASSH
af8223acis 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
.sshdirectory reset,authorized_keysrewrite,passwdattempts, 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
.sshdirectory 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.
- Elastic Security Labs - “Outlaw Linux Malware: Persistent, Unsophisticated, and Surprisingly Effective” - https://www.elastic.co/security-labs/outlaw-linux-malware
- Kaspersky Securelist (Apr 2025) - “Outlaw botnet detected” - https://securelist.com/outlaw-botnet/116444/
- 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
- 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
- Access Now (2026) - Syria sanctions and digital infrastructure - https://www.accessnow.org/syria-sanctions-digital-future/
- 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.