Threat Intelligence Report: DCRat Commodity RAT Ecosystem

Distributed Builder Infrastructure & 21-Month Campaign Analysis

Key Findings At A Glance

01 — Active Botnet C2: ThreatFox classifies ce419619.tw1.ru/L1nc0In.php as an active botnet command-and-control endpoint at 100% confidence. Live victim beaconing is occurring at time of publication.

02–21-Month Campaign: Infrastructure sharing the same builder fingerprint (imphash: fcf1390e9ce472c7270447fc5c61a0c1) has been continuously active since August 2024, documented across Cisco Talos, ArmstrongTechs IOC feeds, and multiple community blocklists.

03 — Distributed Operator Ecosystem: 1,000+ samples share the same imphash. At least four distinct operator behavioral profiles were identified, all using the same commodity RAT. This is not one actor — it is a tool ecosystem.

04 — Fresh Infrastructure Gap: Seed C2 domain ce419619.tw1.ru is absent from Maltrail, pengelana/blocklist, and all verified community feeds at time of investigation. New subdomains are deployed faster than blocklists update.

05 — DNS Evasion TTP: DCRat hardcodes Google DNS (8.8.8.8) as a fallback resolver to bypass enterprise DNS filtering. Confirmed via raw PCAP analysis showing parallel queries to both internal resolver and 8.8.8.8 simultaneously.

Table of Contents

1. Executive Summary
2. Investigation Methodology
3. Malware Analysis
4. Network Forensics
5. Infrastructure Analysis
6. Operator Ecosystem & Attribution
7. MITRE ATT&CK Mapping
8. Detection & Defensive Recommendations
9. Open Questions & Further Investigation
10. Indicators of Compromise
11. Intelligence Sources & Provenance

1. Executive Summary

This report documents a live investigation into an active DCRat (DarkCrystal RAT) campaign, initiated from a single SHA256 hash submitted to MalwareBazaar on May 06, 2026. Through systematic pivoting across four primary evidence sources — MalwareBazaar, VirusTotal, CAPE Sandbox, and raw PCAP analysis — the investigation uncovered a commodity crimeware ecosystem that has been continuously operational since at least August 2024, a period of 21+ months.

What Is DCRat?

DCRat (DarkCrystal RAT) is a commercially available Remote Access Trojan sold on Russian-language cybercrime forums. Written in .NET (MSIL), it provides attackers with full remote control of infected machines including keylogging, screen capture, credential theft, file system access, and the ability to deploy additional payloads. It is a commodity tool — widely available, not custom-built, and used by many independent operators simultaneously.

Think of it like a lock-picking kit sold openly at a hardware store. The kit is the same for everyone who buys it. What matters is who's using it, against which doors, and why.

The Core Finding

This campaign is not the work of a single sophisticated actor. It represents a widely distributed cracked RAT builder toolkit, deployed by an unknown number of low-to-medium sophistication operators who consistently use default builder settings, free Russian subdomain hosting, and automated infrastructure registration pipelines.

The unmodified default C2 endpoint path /L1nc0In.php — appearing across 186 public GitHub repositories and confirmed across all sample clusters — is a builder default, not an actor alias. Any threat intelligence attributing this campaign to a single actor named "L1nc0In" is methodologically unsound.

At time of publication, the seed sample's C2 infrastructure (ce419619.tw1.ru / 92.53.96.172) is not present in any major public blocklist, representing an active defensive gap. Infected machines are actively beaconing to live C2 infrastructure.

2. Investigation Methodology

This investigation followed a primary-evidence-only methodology. Every claim in this report is traceable to a specific technical source that was directly accessed and verified. No secondary blogs, unverified community posts, or AI-generated context were used as evidence.

The Evidence Chain

SEED HASH (MalwareBazaar)
        ↓
STATIC ANALYSIS (VirusTotal) — detection, relationships, infrastructure
        ↓
BEHAVIORAL ANALYSIS (CAPE Sandbox) — execution chain, persistence, evasion
        ↓
NETWORK FORENSICS (PCAP/A-Packets) — raw packet confirmation, DNS TTP
        ↓
THREAT INTEL VALIDATION (ThreatFox) — botnet_cc classification
        ↓
CAMPAIGN CONTEXT (GitHub, Cisco Talos) — timeline, scale, ecosystem
        ↓
COMMUNITY FEED ANALYSIS (Maltrail) — coverage gap identification

3. Malware Analysis

3.1 Sample Overview

The investigation seed is a DCRat sample first submitted to MalwareBazaar by abuse_ch on May 06, 2026 at 10:06:13 UTC. Fifty-eight researchers downloaded the sample within hours of submission. VirusTotal registered 55 out of 70 security vendor detections.

3.2 What The imphash Tells Us

The imphash (fcf1390e9ce472c7270447fc5c61a0c1) is a hash of the PE import table — the list of Windows API functions the binary calls. When malware is built with the same builder or compiler settings, the imphash stays consistent across deployments.

This single imphash matches:

• 906 other DCRat samples on MalwareBazaar
• 118 NanoCore samples — a different RAT family
• 94 njrat samples — another RAT family

The cross-family matches (NanoCore, njrat) indicate the same PureCrypter packaging service was used to pack multiple different RAT families. This is a crypter-as-a-service model — one packer supplier, multiple buyers using different underlying tools.

The dhash icon (9494b494d4aeaeac) matches 903 DCRat samples. The same fake Windows application icon is reused across nearly the entire sample cluster. The operator never changed it — lazy operational security that becomes a durable detection artifact.

3.3 Delivery Mechanism — The SFX Dropper

The sample is packaged as a WinRAR Self-Extracting archive (SFX), confirmed by TrID analysis (92.3% confidence). This is not a standard EXE — it is a ZIP file with execution instructions embedded.

In plain terms: When a victim runs this file, it behaves like any double-clicked program but silently unpacks its contents to a hidden directory without showing any WinRAR interface. The victim sees nothing unusual. The attack has already begun.

The SFX drops files to deliberately obfuscated non-standard directories:

C:\blockcomponentreviewbrokermonitor\   ← nonsense name, looks legitimate at a glance
C:\Recovery\                            ← mimics real Windows recovery directory
C:\Users\Public\                        ← world-writable, no admin rights needed
C:\Program Files\Common Files\Services\ ← masquerades as legitimate service location
C:\Program Files\Windows Multimedia Platform\
C:\Program Files\Windows Mail\

3.4 Execution Chain

CAPE Sandbox behavioral analysis (Analysis ID: 64682) confirmed the following execution chain on a Windows 10 KVM environment over 264 seconds:

216cbcfc190ca10bd85a.exe (PID 2208)
│   SFX dropper executes — unpacks payload bundle silently
│
├── wscript.exe (PID 3296)
│   └── KfNwg5OaUh7u46w8.vbe
│       VBScript Encoded launcher #1 — obfuscated, not human-readable
│
├── cmd.exe (PID 3716)
│   └── onDFCAHPMVDSgyBgL.bat
│       Batch script launcher #2 — redundant parallel execution
│       If VBScript fails, batch still runs. Failsafe design.
│
├── componentwin.exe (PID 1484) ← ⚠️ DCRAT PAYLOAD ACTIVE
│   RAT establishes C2 beacon loop to ce419619.tw1.ru
│
├── cmd.exe (PID 5324)
│   └── %TEMP%\88oL2MlLMG.bat
│       Self-deletion script — erases initial SFX dropper
│       Removes entry point evidence after payload is running
│
├── w32tm.exe (PID 5648)
│   └── /stripchart /computer:localhost /period:5 /samples:2
│       ⚠️ ANTI-SANDBOX EVASION — deliberate 10-second delay
│       Sandbox timeouts miss behavior that executes after this
│
└── Idle.exe (PID 6052) ← ⚠️ SECOND DCRAT INSTANCE
    Redundancy failsafe — if first instance is killed, this continues

Why two launchers and two RAT instances? This is deliberate redundancy engineering. If AV kills componentwin.exe, Idle.exe is still running. If the VBScript gets blocked, the batch file still executes. The actor designed this for resilience, not sophistication.

3.5 The Persistence Bomb — 30+ Scheduled Tasks

This is the most aggressive aspect of the infection. For each of the 12 dropped payloads, three Windows Scheduled Tasks are created, resulting in 30+ total persistence entries across the system.

The three-task pattern per payload:

What this means in practice: You kill one RAT process, it relaunches within minutes. You reboot the machine, it comes back on login. You're not dealing with one malicious process — you're dealing with a self-healing system of 30+ independent revival mechanisms.

The name squatting trick: Every payload uses the name of a real, legitimate Windows system process. The malicious files are in wrong directories:

A junior analyst seeing csrss.exe in a process list thinks "that's normal Windows." A trained analyst checks path + name. The path tells the truth.

Important clarification: This persistence operates entirely in user-mode at administrator level. This is NOT kernel-mode or rootkit behavior. A full system reimage completely removes all persistence. Manual removal requires auditing all scheduled tasks and deleting entries pointing to non-standard paths.

3.6 Evasion Techniques

4. Network Forensics

4.1 PCAP Analysis Overview

Network analysis was performed on the PCAP exported from CAPE Sandbox (64682_dump.pcap, 8.21 KB). The sandbox isolated the sample from the live internet — blocking TCP connections while allowing DNS resolution — resulting in capture of DNS-layer evidence without HTTP payload exfiltration.

4.2 The Dual DNS Resolver TTP — Most Important Network Finding

DCRat sends parallel DNS queries to both the local network resolver AND Google's public DNS (8.8.8.8) simultaneously. This is deliberate evasion of enterprise DNS filtering.

Why this matters: A common corporate defense is to blackhole malicious domains at the internal DNS resolver. If ce419619.tw1.ru is blocked at the company's DNS server, a normal piece of malware would fail to resolve and give up. DCRat doesn't give up — it immediately tries 8.8.8.8 instead. The block is bypassed.

Infected Machine (10.10.0.2)
    │
    ├──── DNS query ────► 10.10.0.1 (Internal Resolver)
    │                     "What IP is ce419619.tw1.ru?"
    │
    └──── DNS query ────► 8.8.8.8 (Google DNS — hardcoded)
                          "What IP is ce419619.tw1.ru?"

Both queries fire simultaneously. Whichever answers first wins. The 8.8.8.8 fallback is hardcoded in the DCRat builder — it appears across the entire sample cluster regardless of campaign. This is the most actionable behavioral detection available.

4.3 The Full DNS Query List

Both resolvers received identical queries in the same order:

1. settings-win.data.microsoft.com    ← Windows telemetry (cover traffic)
2. ocos-office365-s2s.msedge.net      ← Microsoft Edge (cover traffic)
3. client-office365-tas.msedge.net    ← Office 365 (cover traffic)
4. config.edge.skype.com              ← Skype config (cover traffic)
5. fs.microsoft.com                   ← Microsoft file sync (cover traffic)
6. dns.msftncsi.com                   ← Pre-flight connectivity check ⚠️
7. ce419619.tw1.ru                    ← THE C2 BEACON (signal)

The six Microsoft domains are cover traffic — they make the one malicious query look like routine Windows background activity in a proxy log. The dns.msftncsi.com query is a Network Connectivity Status Indicator check — Windows uses this to show "Connected" in the system tray. DCRat hijacks this mechanism to confirm internet access before attempting its C2 beacon. If this check fails, the malware knows it has no internet and doesn't waste an identifiable beacon attempt.

4.4 DNS Resolution Result — Critical Detection Implication

The PCAP shows DNS Failure Types: 100% No Error. The sandbox did not return NXDOMAIN (domain doesn't exist). The C2 domain resolved successfully.

Detection implication: On a corporate network, a successful DNS No Error response for a known malicious domain is itself a high-confidence detection event. You do not need to see the HTTP traffic. The successful DNS resolution is the alert. Any endpoint resolving ce419619.tw1.ru without an error is actively infected and attempting to beacon.

4.5 Beacon Pattern

The traffic timeline from A-Packets visualization shows two traffic bursts at T+0:00 and T+0:01, followed by sustained low-level retry traffic. This is the classic RAT beacon loop signature:

T+0:00  SFX executes, NCSI pre-flight check
T+0:01  C2 beacon fires → DNS resolves → TCP blocked
T+0:02  Retry loop begins — small sustained traffic
T+X     Scheduled tasks relaunch RAT every 5-14 minutes
        Each relaunch = same DNS sequence repeats

5. Infrastructure Analysis

5.1 IP Cluster — 92.53.96.172

VirusTotal passive DNS analysis confirmed 12 DCRat C2 domains resolving to the single IP address 92.53.96.172, hosted on AS9123 TimeWeb Ltd, Saint Petersburg, Russian Federation.

This is a shared hosting node — legitimate sites (lensify.life, kodinskofficial.ru) also resolve to this IP. IP-level blocking will cause collateral damage. Domain-level blocking only.

Confirmed C2 domains on 92.53.96.172:

ce419619.tw1.ru  ← SEED SAMPLE
ca340844.tw1.ru
cc549964.tw1.ru
ce520737.tw1.ru
ce539997.tw1.ru
ck563224.tw1.ru
ck771894.tw1.ru
co944709.tw1.ru
ct547584.tw1.ru
cv327205.tw1.ru
cz762927.tw1.ru
cz946195.tw1.ru

A single TIMEWEB-RU hosting account likely controls all 12 subdomains. A formal abuse report to TIMEWEB-RU would take down the entire cluster simultaneously — a more effective action than individual domain blocking.

5.2 Hosting Platform Analysis

The campaign uses five identified hosting platforms. All are Russian-jurisdiction free or low-cost services, reflecting a consistent cost optimization over operational security philosophy.

The xsph.ru regex (^[a-f][0-9]{7}\.xsph\.ru$) is the tightest detection signature — a through f followed by exactly 7 digits produces near-zero false positives in enterprise DNS monitoring.

5.3 C2 Endpoint Path Taxonomy

Analysis of confirmed C2 URLs and the Cisco Talos Generic Trails section reveals five distinct endpoint naming conventions reflecting different operator sophistication levels:

Type 1 — Builder Default (/L1nc0In.php) The operator deployed DCRat without changing any default settings. This is the most common pattern and the highest-confidence detection indicator. Appears in 186 GitHub repositories spanning August 2024 to May 2026. Our seed sample uses Type 1.

Type 2 — Random Hex (/[8 hex chars].php) Automated per-deployment path generation. Changes per campaign, defeating path-based blocklists, but detectable via domain pattern matching.

Type 3 — DCRS Panel Structure (/DCRS/index.php, /DCRS/dsock/, /DCRS/main.php) Full DCRat panel installation with proper directory structure. More sophisticated setup suggesting the operator invested time in proper deployment.

Type 4 — Obfuscated Descriptive (/externalLowgeotrack.php, /packetlowcpuProtect.php) Manually customized paths designed to blend into legitimate API traffic in web proxy logs. Requires more operator effort — indicates higher security awareness.

Type 5 — Random String Directories (/[40+ char random string]/) Unique per-victim paths, possibly session-based routing. Hardest to detect by path signature alone. Suggests the most sophisticated operators in the ecosystem.

5.4 Campaign Timeline — xsph.ru Sequence Analysis

The xsph.ru subdomain registration numbers provide a unique timeline artifact. Sequential analysis across the imphash cluster reveals a continuous automated registration pipeline operating since at least August 2024:

Aug 2024  → a101xxxx range (ArmstrongTechs IOC feed — earliest confirmed)
Oct 2024  → Cisco Talos documents GoPhish+PowerRAT+DCRat campaign
Dec 2024  → a108xxxx range (MalwareBazaar cluster begins)
Apr 2026  → cy327179.tw1.ru confirmed (Tagoletta Malware-Report)
May 2026  → a116xxxx range (this investigation — seed sample)

Burst registration events: High-density clusters (e.g., a1164274 to a1164290 — 16 sequential registrations in rapid succession) indicate automated bulk deployment scripts firing in bursts. Large numeric gaps (150,000+) between clusters indicate dormant periods or platform switching.

This is not manual infrastructure management — it is an automated subdomain factory that has been running for nearly two years.

6. Operator Ecosystem & Attribution

6.1 The L1nc0In Misconception — Closing This Permanently

The string L1nc0In in the C2 path is not an actor alias. It is a hardcoded default in the DCRat builder that operators consistently fail to change. The evidence is unambiguous:

• 186 GitHub code search results for L1nc0In.php spanning 21 months
• Multiple distinct infrastructure clusters all using the same default simultaneously
• Presence across campaigns documented by separate independent research organizations
• Pattern consistent with a cracked builder distributed freely — operators download and deploy without modification

Correct statement: /L1nc0In.php is a DCRat builder artifact first observed in community IOC feeds August 2024, consistently used by operators who deploy without customization. It is not an actor alias. Attribution based solely on this endpoint path is methodologically unsound.

6.2 Four Operator Groups Identified

Infrastructure pattern analysis across the Cisco Talos IOC dataset and MalwareBazaar imphash cluster reveals at least four distinct behavioral profiles all using the same commodity RAT:

Group 1 — Algorithmic Operators (This Investigation) Infrastructure: tw1.ru / xsph.ru / tmweb.ru with algorithmic subdomain generation. Opsec: LOW — automated bulk registration, default builder settings, high volume. Profile: Optimizing for speed and cost. Thousands of subdomains registered and abandoned. This is the group behind our seed sample.

Group 2 — nyashteam Operators Infrastructure: [0-9]{4,6}.clmonth.nyashteam.{top|ru|ml|site} — a completely different naming convention using numeric IDs and .clmonth./.cllt. path segments across multiple TLDs. Opsec: LOW-MEDIUM — different tooling suggests a separate team or individual. Profile: Possibly a distinct buyer of the same cracked builder with their own infrastructure preferences.

Group 3 — Vanity Domain Operators Infrastructure: dcrat.host, haskers.ru, hesoyam.space (GTA San Andreas cheat code), devil137.ru, cheathub.space. Opsec: LOW — self-identifying domain names, gaming/hacker culture naming conventions. Profile: Younger, gaming community-adjacent operators. hesoyam is a GTA health cheat code — a cultural indicator.

Group 4 — VPS Operators Infrastructure: IP-embedded hostnames on regruhosting.ru (e.g., 194-58-107-59.cloudvps.regruhosting.ru). Opsec: MEDIUM — paying for dedicated VPS instances rather than using free shared hosting. Higher investment suggests higher expected return. Profile: Slightly more professional tier. REG.RU is a major Russian hosting provider.

6.3 Attribution Assessment

ACTOR IDENTITY: UNKNOWN — REQUIRES FURTHER INVESTIGATION

No forum posts, aliases, or identity indicators were found linking to the specific operator(s) behind the seed sample with primary evidence. Forum intelligence was not pursued in Phase 1 to maintain operational security and evidence integrity.

What IS attributable with high confidence:

The bigger picture: This campaign's persistence and scale do not reflect a single careful actor. They reflect a widely available tool that lowers the barrier to entry for crimeware operations. When a sophisticated RAT can be downloaded for free, configured in minutes, and deployed on free hosting, the volume of independent deployments naturally becomes enormous. The 186 GitHub results and 1,000+ MalwareBazaar samples are the inevitable consequence of commoditization, not coordinated campaign activity.

7. MITRE ATT&CK Mapping

All techniques below are confirmed by primary evidence. No inferred techniques are included.

8. Detection & Defensive Recommendations

8.1 High-Confidence Detection Rules

DNS / Network

Rule 1 — Block /L1nc0In.php (Highest Priority) Any HTTP request where the URL path contains /L1nc0In.php is confirmed DCRat C2 activity. False positive rate: near zero.

ALERT: HTTP request WHERE url_path MATCHES "*/L1nc0In.php"
Action: BLOCK + ALERT + Isolate source endpoint

Rule 2 — Algorithmic Subdomain Detection

tw1.ru:    regex ^[a-z]{2}[0-9]{5,6}\.tw1\.ru$
xsph.ru:   regex ^[a-f][0-9]{7}\.xsph\.ru$        ← near-zero false positives
tmweb.ru:  regex ^[a-z]{2}[0-9]{5}\.tmweb\.ru$
beget.tech: regex ^[a-z0-9]{6,10}\.beget\.tech$
nyashteam: regex ^[0-9]{4,6}\.cl(month|lt)\.nyashteam\.(top|ru|ml|site)$

Rule 3 — DNS Failover Evasion Detection

ALERT: Internal host sending DNS query to 8.8.8.8
WHERE: destination domain NOT in approved whitelist
Action: INVESTIGATE — high confidence DNS bypass behavior

Rule 4 — DNS No Error on Malicious Domain A successful DNS resolution (No Error) for any domain in the IOC list is a high-confidence detection event even without HTTP traffic visible.

Endpoint / EDR

Rule 5 — Anti-Sandbox w32tm Abuse

ALERT: w32tm.exe spawned by non-system parent process
WITH args: /stripchart /computer:localhost
Confidence: HIGH — known DCRat sandbox evasion signature

Rule 6 — Scheduled Task Path Anomaly

ALERT: schtasks.exe /create
WHERE task executable path contains:
  C:\Recovery\
  C:\blockcomponentreviewbrokermonitor\
  C:\Users\Public\Desktop\
Action: HIGH confidence malicious persistence — isolate

Rule 7 — Process Name Squatting

ALERT: process_name IN [csrss.exe, wininit.exe, spoolsv.exe,
  lsass.exe, fontdrvhost.exe, ApplicationFrameHost.exe,
  TrustedInstaller.exe, sppsvc.exe]
WHERE process_path NOT LIKE 'C:\Windows\%'
Action: INVESTIGATE immediately

8.2 Strategic Recommendations

Prioritize TTPs over IOCs. Individual domains rotate faster than blocklists update. The imphash (fcf1390e9ce472c7270447fc5c61a0c1) and /L1nc0In.php path are durable fingerprints that will outlive any specific infrastructure deployment. Write detection rules against builder artifacts, not IP addresses.

Deploy DNS-level controls. The dual DNS resolver TTP bypasses perimeter firewall rules that only operate at the IP or TCP layer. DNS filtering that catches the query — regardless of which resolver was used — is the correct defensive layer for this specific threat.

Audit scheduled tasks on endpoints. The persistence bomb creates a large, detectable footprint. Periodic scheduled task auditing for entries pointing to non-standard directories (C:\Recovery\, C:\Users\Public\) will identify infections that survived initial AV scanning.

Consider namespace-level blocking. For enterprises with no legitimate business need for these platforms, blocking *.tw1.ru and *.xsph.ru at the DNS level eliminates a significant portion of this campaign's current and future infrastructure with minimal false positive risk.

Submit fresh IOCs to community feeds promptly. A days-to-weeks lag between fresh infrastructure deployment and community blocklist coverage is the primary defensive gap identified in this investigation. Rapid submission to abuse_ch, Maltrail, and ThreatFox closes this window for the broader community.

9. Open Questions & Further Investigation

The following questions remain unresolved at the conclusion of Phase 1. Each is documented honestly with confidence assessment and proposed next step.

10. Indicators of Compromise

All IOCs below are confirmed by primary technical evidence. Confidence ratings reflect the strength of the evidence chain.

File Hashes

Network Indicators

Behavioral Indicators

Threat Intelligence References

11. Intelligence Sources & Provenance

This report uses a primary-evidence-only sourcing standard. Every source listed below was directly accessed by the analyst. No secondary aggregations were used as evidence.

11.1 Primary Technical Sources

11.2 Community Intelligence Sources

Analyst Notes

This investigation was conducted as a live training session, starting from a single hash with no prior context and building the intelligence picture from zero using open-source primary evidence. The methodology — seed → static → behavioral → network → pivot → ecosystem — is reproducible for any commodity malware investigation.

The most important analytical conclusion is also the simplest: when 186 public GitHub repositories document the same C2 path string across 21 months and multiple distinct infrastructure clusters, you are not looking at one actor's signature. You are looking at the default settings of a tool that too many people forgot to change.

The defensive implication is equally simple: hunting builder defaults and behavioral patterns is more durable than hunting IP addresses. The IPs change daily. The imphash and the PHP path have been consistent for nearly two years.

Document ID: CTI-2026–0506-DCRAT | TLP: WHITE | Macs-hit (Kenneth) — Independent CTI Researcher | May 07, 2026

This report may be freely shared. All claims are backed by primary technical evidence. Open questions are explicitly documented as such. No fabricated statistics, unverified attributions, or AI-generated narratives were used in this report.