Dota mdrfckr:
Six More Days, Two Nodes, Four Profiles
This document extends the observation window from March 23–29 and documents campaign activity across two honeypot nodes. It does not replace the initial brief - it adds new data, refines the behavioral taxonomy, and documents what changed and what remains open.
Methodology and scope
Data collection
- Sensor: Cowrie SSH honeypot (medium-interaction). The campaign was observed on two of three active nodes: Germany (Node 1) and France (Node 3)
- A third node (United States, Node 2) was active during this period but recorded zero sessions attributed to this campaign
- A "session" is defined as a successful SSH authentication followed by at least one post-login command
- All commands are logged with timestamps in NDJSON format; sessions are parsed and classified by automated analyzer
- HASSH fingerprinting is used for cross-session correlation where available
- Sessions with zero post-login commands are excluded from behavioral classification
Session counts
- 666 total successful post-authentication sessions recorded across both nodes
- 597 sessions classified into one of four recurring command-set profiles
- 69 sessions had insufficient command depth or did not match a stable cluster - excluded from profile analysis, included in volume counts
Node distribution
| Node | Sessions | Profiles observed | First session |
|---|---|---|---|
| Node 1 - DE (Frankfurt) | 600 | V0, V1, V2, V3 | Mar 23, 01:42 UTC |
| Node 3 - FR (Paris) | 66 | V0 only | Mar 29, 00:04 UTC |
Behavioral profile clustering
- Sessions are grouped by command-sequence signature: key commands (dota, mdrfckr, base64, crontab, .systemcache, up.txt) are extracted and hashed
- Four recurring profiles (V0–V3) were identified by stable command-set clusters across multiple sessions and IPs
- We cannot fully exclude that some shorter profiles (V0, V1) represent truncated executions, session interruptions, or conditional branches of longer scripts rather than distinct deployed variants
- Where this ambiguity is material, it is noted
What this dataset cannot answer
- Lateral movement success - kthreadadd runs against private address space, but Cowrie cannot observe whether those attempts succeed
- Full credential provenance - the origin of credentials observed in /tmp/up.txt is not directly verifiable from our telemetry
- Operator count or infrastructure - session data reflects behavior; C2 structure, tooling, or operator identity are not directly observable
- Behavior on fully compromised production systems - Cowrie is a medium-interaction emulator; behavior may differ on real hosts
What the extended window showed
The campaign continued at high volume after the initial observation window closed. Across two nodes, we recorded 666 sessions from 546 unique source IPs between March 23 and March 29. Activity peaked sharply on March 26, then dropped, then partially resumed.
The March 26 spike - 236 sessions in a single day, 177 of them from the minimal V0-GHOST profile, from 177 distinct source IPs - does not have a clear explanation in the data. It is consistent with a coordinated wave of execution across many source hosts, followed by retasking or a pause. The triggering mechanism is not observable in this dataset.
Four behavioral profiles
The campaign shows four recurring command-set clusters. We refer to them as behavioral profiles rather than confirmed variants: the data is consistent with four distinct deployed scripts, but we cannot fully exclude that shorter profiles represent truncated executions of longer ones.
| Profile | Sessions | Unique IPs | First seen | Commands | SSH key | Recon | /tmp/up.txt | kthreadadd | .systemcache |
|---|---|---|---|---|---|---|---|---|---|
| V0-GHOST | 253 | 229 | Mar 24, 01:50 | 3 | ✓ | - | - | - | - |
| V1-SCOUT | 25 | 24 | Mar 24, 05:59 | 22 | ✓ | ✓ | - | - | - |
| V2-LITE | 91 | 85 | Mar 23, 02:18 | 24 | ✓ | ✓ | ✓ | - | - |
| V3-LATERAL | 228 | 208 | Mar 23, 01:42 | 29–31 | ✓ | ✓ | ✓ | ✓ | ✓ |
All four profiles share the same RSA backdoor key (comment: mdrfckr)
and open with the same persistence sequence: key injection into
~/.ssh/authorized_keys, password change via chpasswd,
and credential staging to /tmp/up.txt. This three-step sequence
is the common invariant across all 597 classified sessions.
V3-LATERAL was observed first in this dataset. The most feature-complete profile appeared at 01:42 UTC on March 23. V0-GHOST, the minimal profile, was not observed until the following day. That ordering is notable but should not be read as evidence of development sequence - V0 may have been running earlier on hosts outside our observation window, or on credentials that did not match until March 24. One possible interpretation is that a stripped-down profile was deployed at scale after the heavier toolkit had already run its first wave.
Observed: lateral movement chain
Of the four profiles, V3-LATERAL is analytically the most important: it is the only one that contains a credential-staging and private-range scanning chain. The following sequence is reconstructed from observed command logs:
kthreadadd uses the credential written to /tmp/up.txt to attempt
SSH logins across 192.168.x.x and 172.16.x.x - private address
space only. 150 threads, port 22.
Whether these attempts succeed on real infrastructure is not observable from our
honeypot telemetry. What the command sequence shows: the credential used to reach
this session is written to /tmp/up.txt and passed directly to
kthreadadd for private-address scanning.
Defender implication.
An SSH honeypot compromise is not necessarily self-contained if the honeypot
shares subnet space with real infrastructure. kthreadadd will attempt
the compromised credential against every host in the same /16.
Honeypot network isolation from production segments is relevant here.
The campaign marker
Every V3-LATERAL session in our dataset reads and then writes the same file:
/var/tmp/.systemcache436621. The suffix 436621 is consistent
across all 228 V3 sessions, both nodes, and all six days of observation.
This is consistent with a reinfection check: the file appears to serve as a marker
for previously touched systems. It may also function as a campaign-scoping mechanism -
a different operator using the same codebase with a different suffix would produce a
different marker. The consistency of 436621 across time, geography,
and both nodes is consistent with a single coordinated campaign, though operator
count and infrastructure are not observable from telemetry.
Credential targeting: service accounts
The V0-GHOST profile - responsible for the March 26 high-volume sweep - targets a dictionary that includes application-specific service accounts beyond generic system defaults. A selection from observed sessions:
| Username | Associated software / role |
|---|---|
informatica | Informatica data integration platform |
informix | IBM Informix database |
openeuler | Huawei OpenEuler Linux distribution |
teamcity | JetBrains CI/CD server |
controlm | BMC Control-M job scheduler |
keycloak | Red Hat identity and access management |
kubeflow | Machine learning workflows on Kubernetes |
hdfs | Hadoop distributed filesystem |
tigergraph | Graph analytics database |
These usernames do not exist on default Linux installations. The credential list extends beyond generic system defaults and includes names associated with specific software ecosystems - consistent with a broader, application-aware dictionary rather than a purely opportunistic one.
V3-LATERAL shows a different bias: 84 of 228 sessions used root credentials. The full lateral movement profile appears more often with elevated access, which is consistent with a workflow that benefits from root privileges for persistence installation.
France node: first contact on March 29
Node 3 (France) opened port 22 on March 27. On March 29 at 00:04 UTC, the first mdrfckr session was observed - roughly 48 hours after exposure. By end of day: 66 sessions from IPs in Asia, Southeast Asia, and Europe. All 66 used the V0-GHOST profile - minimal key-plant, nothing more.
This is consistent with V0-GHOST operating as a minimal, fast-execution profile: plant the key and terminate quickly. Whether a follow-up sweep with a heavier profile was planned is not known.
Node 2 (US): no sessions observed
The US node recorded zero sessions attributed to this campaign. Node 2 uses a
fixed credential set (sysadmin, dicom, backup)
with non-default passwords - none of which appear in the login patterns seen on
Nodes 1 and 3. Credential mismatch is one possible explanation, but
zero-observation alone cannot isolate cause. Scan coverage, routing, and exposure
timing remain viable alternatives.
What we observed, what we infer, what remains open
- 666 sessions across 2 nodes, Mar 23–29
- V3-LATERAL first in dataset: Mar 23, 01:42 UTC
- V0-GHOST first: Mar 24, 01:50 UTC
- V0-GHOST spike: 177 sessions, 177 IPs, Mar 26
- .systemcache436621 in every V3 session
- /tmp/up.txt written with login credential, read by kthreadadd
- kthreadadd targets 192.168.x.x + 172.16.x.x, 150 threads
- Node 3 first session: Mar 29, 00:04 UTC
- Node 2: 0 sessions in period
- Single coordinated campaign - consistent with shared marker and key across both nodes
- V0-GHOST consistent with a high-volume, low-touch profile; V3 with a more feature-complete intrusion chain
- Mar 26 spike consistent with a coordinated wave of execution; triggering mechanism not observable
- /tmp/up.txt credentials plausibly sourced from real victim environments
- Node 2 zero-hit consistent with credential mismatch; other causes not excluded
- V3 first-seen ordering consistent with heavier profiles preceding stripped variants in this dataset
- Whether V0/V1 are distinct scripts or truncated V3 executions
- Exact origin of all credentials in /tmp/up.txt
- Whether kthreadadd lateral attempts succeed on real networks
- Operator count, C2 infrastructure, or origin
- Why V0-GHOST dropped to zero after Mar 26
- Whether Node 3 will see heavier profiles in subsequent days
Timeline
Indicators of Compromise
These observables are included as detection anchors based on what was directly seen in session logs. Several are campaign-specific - the marker suffix and deployment path in particular may vary across campaigns using the same codebase.
| Type | Value | Confidence |
|---|---|---|
| SSH Key marker | mdrfckr in authorized_keys comment field |
high - invariant across all profiles |
| Campaign marker file | /var/tmp/.systemcache436621 |
high - consistent in all V3 sessions; suffix may vary by campaign |
| Lateral movement binary | kthreadadd |
high - observed directly in command logs |
| Deployment path | /tmp/.X291-unix/.rsync/c/ |
medium - consistent in observed V3 sessions; may vary |
| Credential staging file | /tmp/up.txt |
high - written and consumed in observed sessions |
| Lateral scan targets | 192.168.x.x, 172.16.x.x |
high - observed in kthreadadd invocation |
| Payload archive | dota3.tar.gz |
medium - referenced in decoded payload; not directly captured |
Limitations
- Two-node dataset - findings reflect what was reachable and observable from Germany and France; global campaign scope may differ
- Cowrie medium-interaction emulation - behavior may differ on fully compromised production systems; some command branches may not execute as intended
- Session truncation - shorter profiles (V0, V1) may in part represent sessions cut short by network conditions, sensor timeouts, or conditional logic rather than distinct deployed scripts
- Credential provenance - /tmp/up.txt contents are observed artifacts; we cannot verify the origin of each entry from our telemetry
- Lateral movement outcome - kthreadadd executes against private address space; success or failure of those attempts is not visible to a Cowrie sensor
- Observation window - seven calendar days; longer observation may shift profile ratios, reveal additional variants, or show different campaign phases
Observation is ongoing. Node 3 (France) is now active.
A third geo-diverse node (Singapore) is planned for the coming weeks.