Modern .NET web-shell detection: three independent layers

DNN Defender does not decide that a file is malicious from one filename or one keyword. It routes the artifact by type, evaluates independent engines, and records enough evidence for an operator to understand the final result.

The engine is validated against a controlled malicious-sample corpus and specialized .NET/ASP.NET honeypot intelligence. The current corpus includes compact one-line loaders, ASPXSpy/WSO-style shells, request-driven command execution, reflection and in-memory assembly loading, encoded or encrypted remote payloads, file managers/uploaders, process and PowerShell launch chains, post-exploitation helpers, malicious archive members, and suspicious managed assemblies. Every web-shell family represented in the current validation corpus is expected to produce a malicious or review decision rather than silently returning SAFE.

Smart, Strict, and Alert decisions

• Smart correlates weak signals into behavior: attacker-controlled input, decode/decrypt, dynamic load or process execution, filesystem manipulation, persistence, and command output. Benign reflection or a generic token alone is not enough.
• Strict enforces high-confidence rules and protection policy. A confirmed executable payload can be blocked or quarantined without waiting for the AI layer.
• Alert/Review retains anomalous or incomplete chains for investigation instead of forcing a false Clean verdict. This is important for new, damaged, encrypted, or deliberately minimal samples.

Sensitivity, false positives, and known-good files

DNN Defender is intentionally sensitive to combinations frequently used by attackers: dynamic loading, reflection, decoding, process execution, command input, file manipulation, outbound connections, persistence, and executable content in upload locations. A legitimate administration tool, installer, diagnostic component, or custom module can occasionally use a similar primitive. That trade-off can produce a false positive or, more commonly, a Review Required result. It is preferable to expose an unusual executable artifact for review rather than silently label an unknown implant SAFE.

A reviewed file may be accepted as known-good and added to the baseline, but only after the administrator verifies:

1. the file came from an approved vendor or internal build and the package/hash is authentic;
2. its path, deployment time, signer/version, and business purpose match the approved change;
3. its code or IL behavior explains the detected signals and contains no attacker-controlled execution chain;
4. related files, privileged accounts, scheduled jobs, WAF events, and FIM changes show no incident context; and
5. the exact accepted file hash is recorded with reviewer, reason, and approval time.

Baseline acceptance means this exact reviewed state is trusted. It must not disable the rule globally, allow every file in the folder, or convert future changed hashes into SAFE. If the file changes later, Realtime Monitor, the scanner, and FIM must evaluate it again. Never baseline an artifact merely to make a Critical/Review count disappear.

The three layers

1. Rule Engine identifies high-confidence behavior chains and known dangerous combinations. A single generic token such as reflection, location, or an IP-like string is not sufficient for a blocking rule.
2. AST/structural analysis examines executable source structure. It is applicable to supported text-based server code, not arbitrary binary bytes.
3. AI/semantic model supplies an independent score when the licensed model is available. Its output never changes a clean engine label into a false statement; unavailable or failed engines are shown explicitly.

The scanner loads its packaged ML.NET model from the site's filesystem and runs inference locally in the IIS application process. The file-scanning prediction path does not call a cloud analysis service. Administrators should still review separate email, support, and integration settings before exporting any evidence. A reproducible public false-positive/false-negative benchmark has not yet been published; no percentage should be inferred from the model score. The report names which engine supplied each verdict and shows an unavailable engine as unavailable, not Clean.

The AI layer is intentionally probabilistic. Instead of requiring an exact hash or identical text, it scores a broad combination of weak or ambiguous features—sometimes described operationally as “fuzzy” evidence. A renamed, reordered, string-split, or partially obfuscated variant can therefore remain similar to malicious behavior even when no single literal signature matches. This is probability/semantic scoring, not a claim that one AI score is sufficient for every blocking decision.

Rules and AST/IL analysis attack the problem from the opposite direction: they follow execution primitives that ASP.NET malware must eventually use to achieve its objective. Classic and modern web shells may change names, encoding, comments, control flow, or delivery format, but useful attacker behavior still needs one or more of these steps:

• accept attacker-controlled request, cookie, header, file, or command input;
• decode, decrypt, decompress, or reconstruct the payload;
• dynamically compile, resolve, load, or invoke code through reflection or assembly APIs;
• launch a process, command interpreter, PowerShell, unmanaged bridge, or outbound callback;
• read, write, upload, replace, or enumerate files and configuration;
• return command output, maintain a session, or establish persistence.

Rule correlation detects the dangerous chain; AST/IL analysis identifies the actual call structure even when superficial text has been changed; AI recognizes related combinations that do not fit an exact known rule. An attacker must remove the behavior needed to operate the shell—not merely rename the code—to evade all three layers at once.

Engine labels mean exactly: Blocked/Malicious, Review Required, Clean, or Engine Error. The final action, confidence, overall risk, and individual engine verdicts must agree.

Fast response to a new attack family

Detection is not frozen into one compiled signature list. New honeypot or incident evidence can be converted into a bounded rule, structural behavior pattern, advisory mapping, or updated semantic model and delivered in a signed rule/knowledge or module release. Regression samples are retained so improving detection for a new family does not silently break previously working detections or reintroduce broad binary/text false positives.

For a previously unpublished vulnerability, the exploit may have no CVE-specific rule on day one, but its payload and persistence behavior still has to cross the generic upload, executable-content, source/IL analysis, realtime, FIM, quarantine, and audit controls. This gives the defender both preventive opportunities and multiple independent chances to expose the intrusion.

Full scan and realtime are different clocks

The full scan checks existing eligible files in the background. Realtime Monitor reacts to later filesystem changes. Neither clock proves that a newly written shell could not execute before the watcher and scanner finish. Where a request path is known, Prevention/Strict is the request-time control. See Performance on shared hosting and dedicated IIS for scan pacing, backlog, and operational limits.

Archives

ZIP-like containers are opened recursively within safety limits so an ASPX, ASHX, DLL, PHP, or other executable payload cannot hide behind the archive extension. Investigation rows can show each malicious inner entry as archive.zip!/path/file.aspx, while dashboard KPIs count the physical archive once. This prevents a sample pack with hundreds of payloads from distorting site health.

JSON, RESX, XML/resource metadata, model data, ordinary JavaScript, and source maps are skipped by the server-side web-shell pipeline. An intentional skip is normal control flow and is not stored as SCAN ERROR. Password failures, archive limits, read failures, or unavailable engines remain visible as genuine errors.

Managed DLLs

DLLs are never decoded as UTF-8 and matched as source text. Managed assemblies are inspected with the packaged metadata/IL reader without loading or executing the assembly. The report identifies the assembly, method, call-site, and correlated APIs when relevant. Native PE files require provenance, signature, hash-reputation, or a dedicated native-code engine; they are not promoted to malicious from raw binary text.

Obfuscated reflection loaders

For ASP.NET source, the detection-only canonical view decodes Unicode escapes, normalizes C# verbatim identifiers such as @System.@Reflection.@Assembly, and removes ignorable comments and whitespace. A high-confidence reflection-loader decision still requires a complete behavior chain: request-controlled input, decode/decrypt, assembly resolution and load, then dynamic invocation. Reflection metadata alone is not malicious.

Reading Scan Results

• Keep Threats only selected for daily triage; safe results are hidden unless explicitly shown.
• Filter by action, confidence, engine, path, or time before exporting.
• Treat a server-executable file newly found under Portals as urgent even when it is Review rather than a confirmed rule block.
• Use Create Baseline only after independent verification. Do not use it as an alert-dismissal shortcut.
• Quarantine only after confirming the path, evidence, and business impact.