Web Frameworks: .NET

This is the .NET entry in the Web Frameworks module, and we are going to work it the way a security reviewer actually does: as a code review. Instead of poking at a black box and guessing, we are handed the application's source and asked to find the bugs by reading it, then prove each one on the running lab machine. This is white-box testing. Once we can see how the code is written, the framework-specific mistakes stop being mysteries and become patterns we can grep for.

The .NET ecosystem splits cleanly into two generations, and our lab machine runs both. ASP.NET Framework is the Windows-only platform that has served enterprise line-of-business applications since the early 2000s. You find it behind IIS, serving .aspx Web Forms pages, with a signed __VIEWSTATE blob in every form.ASP.NET Core is the cross-platform successor that drives new development today. It runs controllers and Razor views, uses Entity Framework Core for data access, and binds HTTP requests straight onto C# objects. The two share a language and a runtime but fail in very different ways, and a framework's defaults are exactly where its bugs tend to live.

The lab machine's landing page is a source review viewer with three panes. On the far left is a file tree of the application's source, in the middle is the redacted source itself with syntax highlighting, and on the right is the live application, with a toggle between the two services. We read the redacted source in the middle pane to locate each framework-specific sink, then we exploit the live app on the right to recover the real flag. Secret values such as signing keys and flags are blanked to <REDACTED> in the served source, so the source teaches us WHERE a bug lives, never the secret itself. We recover the real values by attacking the running lab machine.

Learning Objectives

• Read ASP.NET Framework and ASP.NET Core source to locate framework-specific sinks
• Recover a leaked <machineKey> and forge a ViewState payload into remote code execution with ysoserial.net
• Spot a SQL injection that survives Entity Framework Core's parameterisation
• Identify and exploit model binding overposting to escalate to administrator
• Recognise Newtonsoft.Json, TypeNameHandling, and the classic .NET deserialisation sinks, and drive one to RCE

Prerequisites

• Working knowledge of HTTP and the request/response cycle
• Familiarity with Burp Suite and the OWASP Top 10
• Comfort reading C# (no writing required) and using curl from a terminal

Suggested prerequisite rooms: Web Frameworks: Code Review for the read, map, trace, triage, and verify method,Web Frameworks: Java, and Web Frameworks: Python, plus OWASP Top 10 2025: Insecure Data Handling, SQL Injection, and Burp Suite: The Basics.

Machine Access

To begin, click the Start Lab Machine button below and give it a couple of minutes to boot. Everything on the lab machine runs in the browser: the source review viewer at http://MACHINE_IP/, the ASP.NET Core AdminPanel at http://MACHINE_IP:5000/, and the ASP.NET Framework LegacyPortal at http://MACHINE_IP:8080/. The one specialised tool we use is ysoserial.net, a .NET payload generator; it is a Windows executable, so we run it natively on the lab machine itself rather than fighting Windows-executable compatibility on the AttackBox. A restricted attacker account is there for exactly that, with its SSH credentials in the card below. It can only run ysoserial.exe, with no access to the application source, the review viewer's files, or any flag. We connect to it for the first time in Task 2.

Set up your virtual environment

To successfully complete this room, you'll need to set up your virtual environment. This involves starting both your AttackBox (if you're not using your VPN) and Lab Machines, ensuring you're equipped with the necessary tools and access to tackle the challenges ahead.

Attacker machine

Status:Off

Lab machine

Status:Off

Start Lab Machine