TL;DR
Automated penetration testing of Silverlight applications is tricky because Silverlight is old and support for it is dwindling. However, tools like Burp Suite (with extensions), Fiddler, and manual code analysis with decompilers remain useful. Expect to do a lot of work manually.
Silverlight Pentesting Tools & Techniques
Silverlight applications present unique challenges for penetration testing due to their nature as rich internet applications running within a sandbox environment. Fully automated testing is difficult, but here’s how you can approach it:
- Understand the Application
- Before using any tools, map out the application’s functionality. What does it do? What data does it handle?
- Identify entry points – forms, buttons, API calls.
- Intercept and Analyse Traffic with Burp Suite
Burp Suite is your primary tool for understanding communication between the Silverlight application and its server.
- Configure Burp Suite as a proxy. Most browsers can be set to use a proxy at 127.0.0.1:8080.
- Use Burp’s intercepting proxy to capture HTTP(S) requests and responses.
- Look for sensitive data in transit (e.g., passwords, API keys).
- The Burp Suite Professional version is highly recommended as it allows more advanced manipulation of traffic.
- Fiddler for Traffic Analysis
Fiddler can be used similarly to Burp Suite, especially if you’re having trouble with proxy configuration.
- Download and install Fiddler.
- Configure Fiddler to capture HTTPS traffic (requires installing a certificate).
- Inspect requests and responses for vulnerabilities like insecure direct object references or data leakage.
- Decompile the XAP File
The .xap file contains the Silverlight application’s code. Decompiling it allows you to examine the C# source code for vulnerabilities.
- Download the .xap file from the server (usually accessible via a URL).
- Use a decompiler like de4dot or Silverlight Spy (older, but sometimes useful).
-
de4dot -in input.xap -out output.dll - Examine the decompiled code for hardcoded credentials, insecure logic, or potential remote code execution vulnerabilities.
- Manual Code Analysis
This is where most of your effort will be focused.
- Look for common web application vulnerabilities within the decompiled C# code:
- SQL injection (if database interaction exists)
- Cross-site scripting (XSS) – particularly in areas where user input is processed.
- Insecure deserialization
- Authentication and authorization flaws
- Dynamic Analysis with Debugging
Use a debugger (like Visual Studio) to step through the Silverlight code while it’s running. This helps understand how data is processed and identify potential vulnerabilities.
- Attach a debugger to the running Silverlight application.
- Set breakpoints at critical points in the code.
- Inspect variables and memory to identify unexpected behaviour or security flaws.
- Consider Security Features
Silverlight had some built-in security features, but they are often bypassed.
- Check if the application uses ClickOnce deployment for code signing verification.
- Examine the application’s sandbox settings to see what permissions it has.
Important Note: Silverlight is end-of-life, meaning security updates are no longer provided. Any vulnerabilities found should be considered critical and require immediate attention if the application remains in use.

